11 Mar
2023
11 Mar
'23
12:09 a.m.
Larry Stewart wrote in
<498576F7-6881-4176-B187-F4ACB0A42F76(a)serissa.com>:
|TLDR exceptions don't make it better, they make it different.
...
|On the whole, I came away with a great deal of grudging respect for \
|ERRNO as striking a great balance between ease of use and specificity.
From my user space point of view i never understood why there is
no dedicated hardware register / (plus) error indicating flag that
callers could cheaply and easily test. (Maybe there is on some
processor platforms, beside a one such where errno then can be
placed in some per-thread structure stored there. Still this
requires another dedicated return value.)
I ran away from the exceptions i got used to with JAVA to
-fno-rtti -fno-exceptions when i looked at the object output of
g++ 2.95.?, and saw in the support code they use heap memory for
this etc.
|I also evolved Larry's Theory of Exceptions, which is that it is the \
|programmer's job to sort exceptional conditions into actionable categori\
|es: (1) resolvable by the user (bad arguments) (2) Temporary (out of \
|network sockets or whatever) (3) resolvable by the sysadmin (config) \
|(4) real bug, resolvable by the author.
...
Really interesting point, like SMTP and other protocols which
classify errors in categories.
Errors are one of my waving-helplessly topics, where you simply
have to let things go and where "perfection" just cannot be
achieved in real-life (or add .. as time passes by).
Often you just do not find the correct answer, with errno the name
sometimes fits, but the decade-old description does not really,
and very fast you end up with overloading (eg come to a second
ENODATA because ESRCH is something different, or reuse EILSEQ for
bogus input even though the function already used to use EILSEQ
for non-convertible output).
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)