Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #146039

Re: error_t proposal

Show all headers | View raw

Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On Thursday, 5 September 2019 14:08:23 UTC+1, Thiago Adams  wrote:
>> On Thursday, September 5, 2019 at 9:35:35 AM UTC-3, Malcolm McLean wrote:
>> > On Thursday, 5 September 2019 13:16:46 UTC+1, Thiago Adams  wrote:
>> > > On Thursday, September 5, 2019 at 8:57:31 AM UTC-3, Thiago Adams wrote:
>> > > ...
>> > > > What is interesting to notice is that the problem of 
>> > > > 'error code sets' is not only from lib to lib but the
>> > > > same lib in different OS.
>> > > 
>> > > The other approach I have seen in Windows for avoiding error
>> > > conversion is to use the same error type used in windows.
>> > > For instance, windows has HRESULT, then instead creating
>> > > MyLibErrorCode or MyProgramErrorCode windows programmers 
>> > > can choose to use HRESULT in their own code.
>> > > Sometimes function that have zero Windows dependencies uses
>> > > HRESULT.
>> > > 
>> > Then it has a Windows dependency.
>> Yes. I don't like this practice.
>>
> An integrated error system will take some designing. For performance
> reasons, an error_t will probably have to be an int. Whilst that gives
> enough codes for each library to define as many error types as it
> needs, it doesn't give enough space to avoid error code collisions.

I've always thought that the linker should have the ability to resolve
symbolic enumeration values of a shared enumeration type (i.e. defined in
fragments) to globally unique values. For statically compiled languages like
Rust it's even easier. But as far as I know, no language provides such a
feature. In dynamic languages it's easy--you just request a value or range
of values to bind to variable names at runtime, which is exactly what the
linker would be doing, except the linker would have to substitute the
resolved values in the code itself.

> Then errors need tagging with error-specific data, plus data common
> to all errors such as the line on which it occurred and the call
> stack trace to show how it got there. If you fail to open a file,
> the user wants to know what name was passed to fopen(), if a memory
> allocation request fails, the debugging programmer wants to know the
> size of the allocation request, and so on. 

A shared error_t gets you 80% of the way to a practical composability
utopia. Yes, context is important, but *usually* the caller has the context
directly (e.g. they passed the file path) or indirectly (e.g. they have a
handle to the resource from which they can query the file path used). Issues
like memory allocation and ownership of *arbitrary* context are effectively
intractable, particularly in a language like C, so asking for such a
capability is as useful as asking for World Peace.

FWIW, I *do* use a shared error_t values in most of my C projects. My
standard header preamble for every major component of a project usually
begins something like:

  #define FOO_EBASE -(('f' << 24) | ('o' << 16) | ('o' << 8) | 64)
  #define FOO_ISERRNO(e) ((e) >= FOO_EBASE && (e) < FOO_ELAST)

  #define foo_error_t int /* for API documentation only */

  enum foo_errno {
    FOO_EBAR = FOO_EBASE,
    FOO_EBAZ,
    // ...
    FOO_ELAST,
  };

  const char *foo_strerror(foo_error_t);

where foo_strerror will forward unknown values to any component it uses and
for which it may have returned an error value, otherwise as a fail-safe it
proxies to strerror(3), which will always produce a valid result even for
unknown values. (Invariably system errors are a subset of the errors
returned as foo_error_t, so excepting bugs in the application strerror(3) is
really only invoked for system errno values.)

I might sometimes have something like:

  const char *foo_strerror(foo_error_t, struct foo *ctx);

But IME the relevant context is usually already available to the caller. And
if it's not that's a clue that my code and APIs need to be restructured so
the caller does have access to the relevant context, rather than boiling the
oceans chasing the perfect error reporting API.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-04 14:14 -0700
  Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-04 15:20 -0700
    Re: error_t proposal Mateusz Viste <mateusz@wont.tell> - 2019-09-05 08:02 +0000
      Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 04:04 -0700
        Re: error_t proposal Bruce S <bruces42@hotmail.com> - 2019-09-05 08:18 -0600
          Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-05 14:31 -0700
            Re: error_t proposal James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-05 17:49 -0400
              Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-05 15:14 -0700
            Re: error_t proposal Bruce S <bruces42@hotmail.com> - 2019-09-06 14:03 -0600
  Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-05 09:30 +1000
    Re: error_t proposal Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-05 02:38 -0700
    Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 04:57 -0700
      Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 05:16 -0700
        Re: error_t proposal Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-05 05:35 -0700
          Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 06:08 -0700
            Re: error_t proposal Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-05 06:16 -0700
              Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 06:37 -0700
                Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 07:04 -0700
                Re: error_t proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-05 20:51 +0100
                Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 13:52 -0700
                Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-05 14:56 -0700
              Re: error_t proposal William Ahern <william@25thandClement.com> - 2019-09-05 13:18 -0700
              Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-06 07:25 +1000
      Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-06 07:35 +1000
        Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 04:22 -0700
    Re: error_t proposal scott@slp53.sl.home (Scott Lurndal) - 2019-09-05 13:59 +0000
      Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-06 07:10 +1000
  Re: error_t proposal Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-05 10:01 +0000
    Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 04:36 -0700
      Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-05 14:43 -0700
        Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 05:01 -0700
          Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-06 11:18 -0700
            Re: error_t proposal scott@slp53.sl.home (Scott Lurndal) - 2019-09-06 19:34 +0000
            Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 12:37 -0700
              Re: error_t proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-06 20:54 +0100
                Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-06 13:20 -0700
                Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 13:43 -0700
                Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-06 14:25 -0700
                Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 15:14 -0700
                Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-06 15:49 -0700
                Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 18:44 -0700
                Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-07 12:35 +1000
                Re: error_t proposal Ike Naar <ike@sdf.lonestar.org> - 2019-09-08 20:15 +0000
                Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-09 09:30 +1000
                Re: error_t proposal Ike Naar <ike@iceland.freeshell.org> - 2019-09-09 07:35 +0000
                Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-09 19:44 +1000
                Re: error_t proposal scott@slp53.sl.home (Scott Lurndal) - 2019-09-09 13:58 +0000
                Re: error_t proposal Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-10 14:24 +0000
                Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-11 09:22 +1000
                Re: error_t proposal Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-10 16:48 -0700
                Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-11 10:45 +1000
                Re: error_t proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-06 21:47 +0100
  Re: error_t proposal jadill33@gmail.com - 2019-09-05 07:04 -0700
    Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 07:36 -0700
      Re: error_t proposal jadill33@gmail.com - 2019-09-05 08:43 -0700

csiph-web