Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
10 Mar
2023
10 Mar
'23
2:20 p.m.
TLDR exceptions don't make it better, they make it different.
The Mesa and Cedar languages at PARC CSL were intended to be "Systems Languages"
and fully embraced exceptions.
The problem is that it is extremely tempting for the author of a library to use them, and
equally tempting for the authors of library calls used by the first library, and so on.
At the application level, literally anything can happen on any call.
The Cedar OS was a library OS, where applications ran in the same address space, since
there was no VM. In 1982 or so I set out to write a shell for it, and was determined that
regardless of what happened, the shell should not crash, so I set out to guard every
single call with handlers for every exception they could raise.
This was an immensely frustrating process because while the language suggested that the
author of a library capture exceptions on the way by and translate them to one at the
package level, this is a terrible idea in its own way, because you can't debug - the
state of the ultimate problem was lost. So no one did this, and at the top level,
literally any exception could occur.
Another thing that happens with exceptions is that programmers get the bright idea to use
them for conditions which are uncommon, but expected, so any user of the function has to
write complicated code to deal with these cases.
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.
I also evolved Larry's Theory of Exceptions, which is that it is the
programmer's job to sort exceptional conditions into actionable categories: (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.
The usual practice of course is the popup "Received unknown error, OK?"
-Larry
On Mar 10, 2023, at 8:15 AM, Ralph Corderoy
<ralph(a)inputplus.co.uk> wrote:
Hi Noel,
Thanks for clarifying; I did know it was a possibility.
if you
say above that most people are unfamiliar with them due to
their use of goto then that's probably wrong
I didn't say that. I was just astonished that in a long thread about
handling exceptional
conditions, nobody had mentioned . . . exceptions. Clearly, either
unfamiliarity (perhaps because not many laguages provide them - as you
point out, Go does not), or not top of mind.
Or perhaps those happy to use gotos also tend to be those who dislike
exceptions. :-)
Anyway, I'm off-TUHS-pic so follow-ups set to goto COFF.
--
Cheers, Ralph. 
10 Mar
10 Mar
6:09 p.m.
New subject: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
Larry Stewart wrote in
<498576F7-6881-4176-B187-F4ACB0A42F76(a)serissa.com>om>:
|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)
419
days inactive
419
days old
1 comments
2 participants
participants (2)
-
Larry Stewart -
Steffen Nurpmeso