On the flip side something I've always thought would be powerful, at least in development, is a way to tell any and all procedures being called to ignore their exception/condition handling and hard-crash. Of course you don't want to take that kind of hammer to a production situation, but a way to override any and all handling so that real errors become apparent would be incredibly nice.

During development the runtime should simply invoke a debugger in this case. This should be perfectly doable but for some reason it is considered acceptable to crash a program! I don???t want to run a program *under a debugger* but want it invoked at the right time!

Hi Larry, I also came up with this, probably on an SGI Iris Indigo, and got it added to the Unix Programming FAQ. :-) 6.5 How can I generate a stack dump from within a running program? http://www.faqs.org/faqs/unix-faq/programmer/faq/ It works surprisingly often, i.e. the process is healthy enough to run system(3).

Do you ever find things are so messed up that stdio has trouble whereas using write(2) with compile-time memory allocations for a buffer would have a better chance of reaching the TTY?

During development the runtime should simply invoke a debugger in this case. This should be perfectly doable but for some reason it is considered acceptable to crash a program! I don’t want to run a program *under a debugger* but want it invoked at the right time! >  > On the flip side something I've always thought would be powerful, at least in development, is a way to tell any and all procedures being called to ignore their exception/condition handling and hard-crash. Of course you don't want to take that kind of hammer to a production situation, but a way to override any and all handling so that real errors become apparent would be incredibly nice. > > If nothing else, I could provide much better stack traces to vendors when I'm particularly stuck on something and convinced it isn't my fault. Maybe such a thing exists in C# but I've never gone looking for it, all I know is catching an exception from some vendor library with zero useful information makes me want to take a hammer to much more than the code... > > - Matt G. > ------- Original Message ------- > On Friday, March 10th, 2023 at 9:11 AM, Bakul Shah <bakul(a)iitbombay.org> wrote: > >> To make exceptional handling robust, I think every exception needs to be explicitly handled somewhere. If an exception not handled by a function, that fact must be specified in the function declaration. In effect the compiler can check that every exception has a handler somewhere. I think you can implement it using different syntactic sugar than Go’s obnoxious error handling but basically the same (though you may be tempted to make more efficient). >> >>> On Mar 10, 2023, at 6:21 AM, Larry Stewart <stewart(a)serissa.com> wrote: >> >>> 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, >>> >>>> >>> >>>>>> 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. >>> >>>> >>> >>>> Thanks for clarifying; I did know it was a possibility. >>> >>>> >>> >>>>> 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.

On Fri, Mar 10, 2023 at 12:36 PM Bakul Shah <bakul(a)iitbombay.org> wrote: Common Lisp implementations have been doing that for years! Too bad using Lisp means bringing all the rest of the Lisp stuff with it, including the attitude. Oh well. :-)

While all this error and exception discussion is going down, I have to mention this piece: http://joeduffyblog.com/2016/02/07/the-error-model/ The author worked at MS on their "midori" research OS, and discussed what went into their decisions around using return codes, exceptions, etc. I felt it was a nice breakdown of the pros and cons of the different approaches, and fleshed out the concepts in my mind a bit. I thought others might enjoy it as well.

That said, I absolutely loathe exceptions with all my heart.

From a compiler writer's perspective, the name STD for the C++ Standard Library is most apt. STD routines are a disease that infects anything that touches them.