Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #146003
| Subject | Re: error_t proposal |
|---|---|
| Newsgroups | comp.lang.c |
| References | <5d03868d-22f7-4c7f-9f9b-1e70d8d8e6f2@googlegroups.com> |
| From | Clifford Heath <no.spam@please.net> |
| Message-ID | <5OXbF.196928$9i3.77232@fx42.iad> (permalink) |
| Date | 2019-09-05 09:30 +1000 |
On 5/9/19 7:14 am, Thiago Adams wrote:
> In my experience, most of the time I don't need to check
> for specific errors.
>
> For instance, I rarely need to do this:
>
> if (error == specific_error) {
> /*do something*/
> }
>
> in general I just check for general errors:
>
> if (error != error_success) {
> /*do something*/
> }
>
> Some libraries uses 0 to say "no error" and others use
> 1 or true do say "no error".
>
> My suggestion is to add at <errno.h>
>
> typedef int error_t
> and a enum item std_success
>
>
> If you look at existing code, for instance
>
> int thrd_create( thrd_t *thr, thrd_start_t func, void *arg );
> "thrd_success if the creation of the new thread was successful."
>
>
> int bind(SOCKET s, const sockaddr *addr, int namelen);
> "If no error occurs, bind returns zero. Otherwise, it returns SOCKET_ERROR, and a specific error code can be"
>
> You will see different approaches.
>
> But I think it should be more universal and library implementers
> could use the same typedef.
>
> Let's say
>
> error_t MyLibFunc();
>
> then I could use
>
> error_t er = MyLibFunc();
>
> if (er != std_success)
> {
> printf("%s", MyLibErrorToString(er));
> }
>
> and then automatically, the programmer that is using that lib
> knows how do check for errors.
>
>
> What do you think?
Errno is possibly the most evil thing to happen in the history of the
computer industry.
Every error has a context which goes beyond a simple indication of
failure. The very first errno in Unix is EPERM, permission denied. There
is no indication of what permission was denied, or what the user can do
to fix it. The second one is ENOENT, no such file or directory. Exactly
*which* file or directory (in the path provided) does not exist?
Perchance you could tell me whether it was expected to be a file, or a
directory? And so it goes on.
This problem of missing context from error reports was copied by
Microsoft (who hasn't laughed at a dialog saying "Unknown Error
0x80000000"?) and the cultural phenomenon went on to become by far the
single biggest single cause of user frustration in all computing. We've
even trained our users to expect it, when they should be screaming blue
murder. We have normalised this insanity.
Every primary error indication should contain or make available every
detail that isn't implicit from the call. Errno and the culture
surrounding that says "too hard, don't care, f*ck the users, they can
work it out by themselves". It embodies a culture of deep disrespect.
> How do you propagate errors? Do you create your own type?
I made (for our company in the late 1980's, and still in use now) a kind
of exception management environment. It's complicated. It deserves a
book all by itself, or at least several chapters in one.
In C++, we were using many different early compilers (targeting 50+
platforms) so couldn't rely on much, and especially not on exceptions.
But I defined a type which contained a 32-bit error code called ErrorT
broken into a module (subsystem) ID and a message number within that
module (we called these the S/M numbers). The error numbers were
generated into a C++ header by a compiler for our Error Catalog Source
language, and that was integrated into the makefile process. So you
can't allocate a number at random, you can only use one that's been
properly defined. And here, "properly defined" meant that message text
was made available in each language, with type-safe argument
interpolation. It also meant that sufficient documentation was provided
to generate a PDF error messages manual that had useful content, and for
translators to know how to translate to a new language. We expected that
each message would usually be broken into Problem/Reason/Solution, since
that was usually appropriate.
The definition of an ErrorT included defining the parameters for each
error. The constructor for each error code requires the parameters, like
with an exception.
But here's where this diverges from being just a fancy exception system.
To create an ErrorT to return, it's necessary to provide the parameters
to a type-safe varargs-style function (I won't go into how we did that
but it was pretty fast). The error code and the parameter values were
pushed onto an error tombstone (stack). If the caller doesn't take
corrective action and unwind this stack (discarding the copied
parameters), a top-level GUI loop (or atexit function) would fetch all
appropriate message text, format the messages and spit them out. So you
got a full cause-and-effect chain report. The message cascade could even
be serialised over a network to be formatted into a remote user's native
language.
E.g.
Your project "Some Work" could not be saved. Please save it elsewhere.
-> Failed to write file "a/b/c".
-> Out of space on volume "/mnt/work", free up space and try again.
and sometimes much more complicated error cascades. It really wasn't
costly at runtime, and the discipline it imposed on developers was
excellent for them personally as well as for the company and our users.
Clifford Heath.
> Do you use enun or int?
> How do you integrate errors from thirty party libs in our own
> errors?
>
>
> Apart of that some range could be reserved for known errors.
> E.g nomen or io errors.
>
> then errors like
>
> thrd_nomem
>
> would not need a specific namespaces.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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