Computer Old Farts Forum
 help / color / mirror / Atom feed
* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
@ 2023-03-10 17:11 Bakul Shah
  2023-03-10 17:28 ` segaloco via COFF
  0 siblings, 1 reply; 21+ messages in thread
From: Bakul Shah @ 2023-03-10 17:11 UTC (permalink / raw)
  To: Larry Stewart; +Cc: coff

[-- Attachment #1: Type: text/plain, Size: 3300 bytes --]

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@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@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.

[-- Attachment #2: Type: text/html, Size: 5390 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
  2023-03-10 17:11 [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Bakul Shah
@ 2023-03-10 17:28 ` segaloco via COFF
  2023-03-10 17:34   ` Larry McVoy
                     ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: segaloco via COFF @ 2023-03-10 17:28 UTC (permalink / raw)
  To: Bakul Shah; +Cc: coff

[-- Attachment #1: Type: text/plain, Size: 4228 bytes --]

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@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@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@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.

[-- Attachment #2: Type: text/html, Size: 6542 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
  2023-03-10 17:28 ` segaloco via COFF
@ 2023-03-10 17:34   ` Larry McVoy
  2023-03-10 17:35   ` Bakul Shah
  2023-03-10 17:47   ` [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Bakul Shah
  2 siblings, 0 replies; 21+ messages in thread
From: Larry McVoy @ 2023-03-10 17:34 UTC (permalink / raw)
  To: segaloco; +Cc: coff

On Fri, Mar 10, 2023 at 05:28:44PM +0000, segaloco via COFF wrote:
> 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.

#include <assert.h>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
  2023-03-10 17:28 ` segaloco via COFF
  2023-03-10 17:34   ` Larry McVoy
@ 2023-03-10 17:35   ` Bakul Shah
  2023-03-10 17:42     ` Larry McVoy
                       ` (2 more replies)
  2023-03-10 17:47   ` [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Bakul Shah
  2 siblings, 3 replies; 21+ messages in thread
From: Bakul Shah @ 2023-03-10 17:35 UTC (permalink / raw)
  To: segaloco; +Cc: coff

[-- Attachment #1: Type: text/plain, Size: 4675 bytes --]

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 Mar 10, 2023, at 9:28 AM, segaloco <segaloco@protonmail.com> wrote:
> 
> 
> 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@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@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@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.
>>> 
> 

[-- Attachment #2: Type: text/html, Size: 7174 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
  2023-03-10 17:35   ` Bakul Shah
@ 2023-03-10 17:42     ` Larry McVoy
  2023-03-11 11:28       ` [COFF] Conditions, AKA exceptions Ralph Corderoy
  2023-03-10 17:43     ` [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) segaloco via COFF
  2023-03-10 18:03     ` Dan Cross
  2 siblings, 1 reply; 21+ messages in thread
From: Larry McVoy @ 2023-03-10 17:42 UTC (permalink / raw)
  To: Bakul Shah; +Cc: segaloco, coff

On Fri, Mar 10, 2023 at 09:35:44AM -0800, Bakul Shah wrote:
> 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!

Indeed.

void
gdb_backtrace(void)
{
        FILE    *f;
        char    *cmd;

        unless (getenv("_BK_BACKTRACE")) return;
        unless ((f = efopen("BK_TTYPRINTF")) ||
            (f = fopen(DEV_TTY, "w"))) {
                f = stderr;
        }
        cmd = aprintf("gdb -batch -ex backtrace '%s/bk' %u 1>&%d 2>&%d",
            bin, getpid(), fileno(f), fileno(f));

        system(cmd);
        free(cmd);
        if (f != stderr) fclose(f);
}


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
  2023-03-10 17:35   ` Bakul Shah
  2023-03-10 17:42     ` Larry McVoy
@ 2023-03-10 17:43     ` segaloco via COFF
  2023-03-10 18:03     ` Dan Cross
  2 siblings, 0 replies; 21+ messages in thread
From: segaloco via COFF @ 2023-03-10 17:43 UTC (permalink / raw)
  To: Bakul Shah; +Cc: coff

[-- Attachment #1: Type: text/plain, Size: 5233 bytes --]

Yeah it's a pain and different in different languages. My horror stories are mainly C# since that's what day job stuff is these days (backend anyway). The way assert does it is great, one little cpp define and it all goes away. However that being compile time, only applies to what is yours, if you're stuck with someone else's object code, you get what you get :/

- Matt G.
------- Original Message -------
On Friday, March 10th, 2023 at 9:35 AM, Bakul Shah <bakul@iitbombay.org> wrote:

> 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 Mar 10, 2023, at 9:28 AM, segaloco <segaloco@protonmail.com> wrote:
>
>> 
>> 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@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@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@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.

[-- Attachment #2: Type: text/html, Size: 7914 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
  2023-03-10 17:28 ` segaloco via COFF
  2023-03-10 17:34   ` Larry McVoy
  2023-03-10 17:35   ` Bakul Shah
@ 2023-03-10 17:47   ` Bakul Shah
  2 siblings, 0 replies; 21+ messages in thread
From: Bakul Shah @ 2023-03-10 17:47 UTC (permalink / raw)
  To: segaloco; +Cc: coff

I should add that (compared to goto or setjmp/longjmp), by making exceptions a language thing, the compiler can attach more context to the exception event (or condition). In the scheme I outlined, the vendor library function must declare what exceptions it doesn’t handle and the compiler can pass more context that may not make sense to a library user but may help its developer pinpoint the cause.

> On Mar 10, 2023, at 9:28 AM, segaloco <segaloco@protonmail.com> wrote:
> 
> 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...

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
  2023-03-10 17:35   ` Bakul Shah
  2023-03-10 17:42     ` Larry McVoy
  2023-03-10 17:43     ` [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) segaloco via COFF
@ 2023-03-10 18:03     ` Dan Cross
  2023-03-10 18:57       ` Bakul Shah
  2 siblings, 1 reply; 21+ messages in thread
From: Dan Cross @ 2023-03-10 18:03 UTC (permalink / raw)
  To: Bakul Shah; +Cc: segaloco, coff

On Fri, Mar 10, 2023 at 12:36 PM Bakul Shah <bakul@iitbombay.org> wrote:
> 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!

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. :-)

        - Dan C.


> 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@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@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@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.
>
>
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
  2023-03-10 18:03     ` Dan Cross
@ 2023-03-10 18:57       ` Bakul Shah
  2023-03-10 19:57         ` Marshall Conover
  0 siblings, 1 reply; 21+ messages in thread
From: Bakul Shah @ 2023-03-10 18:57 UTC (permalink / raw)
  To: Dan Cross; +Cc: segaloco, coff

On Mar 10, 2023, at 10:03 AM, Dan Cross <crossd@gmail.com> wrote:
> 
> On Fri, Mar 10, 2023 at 12:36 PM Bakul Shah <bakul@iitbombay.org> wrote:
>> 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!
> 
> 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. :-)

It can even fix the problem and continue!

Note that such things don't have to be *tied* to Lisp. But that
would require a change in mindset.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
  2023-03-10 18:57       ` Bakul Shah
@ 2023-03-10 19:57         ` Marshall Conover
  2023-03-13 16:47           ` [COFF] Conditions, AKA exceptions Ralph Corderoy
  0 siblings, 1 reply; 21+ messages in thread
From: Marshall Conover @ 2023-03-10 19:57 UTC (permalink / raw)
  To: Bakul Shah; +Cc: segaloco, coff

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

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. In my
experience, along Warner and Matt's lines, they're more prone to the sort
of abuse that wastes my time than they are productive. It's not that they
can't be used well, they just so often aren't.

Cheers,

Marshall

On Fri, Mar 10, 2023 at 1:57 PM Bakul Shah <bakul@iitbombay.org> wrote:

> On Mar 10, 2023, at 10:03 AM, Dan Cross <crossd@gmail.com> wrote:
> >
> > On Fri, Mar 10, 2023 at 12:36 PM Bakul Shah <bakul@iitbombay.org> wrote:
> >> 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!
> >
> > 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. :-)
>
> It can even fix the problem and continue!
>
> Note that such things don't have to be *tied* to Lisp. But that
> would require a change in mindset.

[-- Attachment #2: Type: text/html, Size: 2254 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Conditions, AKA exceptions.
  2023-03-10 17:42     ` Larry McVoy
@ 2023-03-11 11:28       ` Ralph Corderoy
  2023-03-12  4:23         ` [COFF] " Theodore Ts'o
  0 siblings, 1 reply; 21+ messages in thread
From: Ralph Corderoy @ 2023-03-11 11:28 UTC (permalink / raw)
  To: coff

Hi Larry,

>         cmd = aprintf("gdb -batch -ex backtrace '%s/bk' %u 1>&%d 2>&%d",
>             bin, getpid(), fileno(f), fileno(f));
>
>         system(cmd);

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).

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: Conditions, AKA exceptions.
  2023-03-11 11:28       ` [COFF] Conditions, AKA exceptions Ralph Corderoy
@ 2023-03-12  4:23         ` Theodore Ts'o
  2023-03-12 10:44           ` Ralph Corderoy
  0 siblings, 1 reply; 21+ messages in thread
From: Theodore Ts'o @ 2023-03-12  4:23 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: coff

On Sat, Mar 11, 2023 at 11:28:49AM +0000, Ralph Corderoy wrote:
> Hi Larry,
> 
> >         cmd = aprintf("gdb -batch -ex backtrace '%s/bk' %u 1>&%d 2>&%d",
> >             bin, getpid(), fileno(f), fileno(f));
> >
> >         system(cmd);
> 
> 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).

On Linux (or some other system using glibc) a limited facility is
built into the C library.  So you can just do somthing like this:

       {
	       void *stack_syms[32];
	       int frames;

	       frames = backtrace(stack_syms, 32);
	       backtrace_symbols_fd(stack_syms, frames, 2);
       }

This is convenient if you want a stack trace, but the binary might be
on a rescue floppy which doesn't have space for gdb, or the user might
not have gdb installed.  I use this for the fsck for ext4, and the
nice thing is that even with a stripped binary.

For example:

Signal (7) SIGBUS (sent from pid 4261) si_code=SI_USER 
e2fsck(+0x36691)[0x564da1ed2691]
/lib/x86_64-linux-gnu/libc.so.6(+0x3bf90)[0x7f6e21c0bf90]
/lib/x86_64-linux-gnu/libc.so.6(read+0xd)[0x7f6e21cc80ed]
e2fsck(ask_yn+0x1de)[0x564da1ec90de]
e2fsck(fix_problem+0xfc0)[0x564da1ecc7b0]
e2fsck(+0x235b3)[0x564da1ebf5b3]
e2fsck(+0x252d3)[0x564da1ec12d3]
/lib/x86_64-linux-gnu/libext2fs.so.2(ext2fs_dblist_iterate3+0x5f)[0x7f6e21e430cf]
e2fsck(e2fsck_pass2+0x18b)[0x564da1ebdd7b]
e2fsck(e2fsck_run+0x5a)[0x564da1eb0c3a]
e2fsck(main+0x16cb)[0x564da1eacdbb]
/lib/x86_64-linux-gnu/libc.so.6(+0x2718a)[0x7f6e21bf718a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85)[0x7f6e21bf7245]
e2fsck(_start+0x21)[0x564da1eaefc1]

For more information see:

https://github.com/tytso/e2fsprogs/blob/master/e2fsck/sigcatcher.c#L379

							- Ted

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: Conditions, AKA exceptions.
  2023-03-12  4:23         ` [COFF] " Theodore Ts'o
@ 2023-03-12 10:44           ` Ralph Corderoy
  2023-03-12 16:46             ` Paul Winalski
  0 siblings, 1 reply; 21+ messages in thread
From: Ralph Corderoy @ 2023-03-12 10:44 UTC (permalink / raw)
  To: coff

Hi Ted,

> > >         cmd = aprintf("gdb -batch -ex backtrace '%s/bk' %u 1>&%d 2>&%d",
> > >             bin, getpid(), fileno(f), fileno(f));
...
> > It works surprisingly often, i.e. the process is healthy enough to
> > run system(3).
>
> On Linux (or some other system using glibc) a limited facility is
> built into the C library.  So you can just do somthing like this:
...
> 	       frames = backtrace(stack_syms, 32);
> 	       backtrace_symbols_fd(stack_syms, frames, 2);

Since ’99, yes.  :-)  backtrace(3) says glibc 2.1 added it.

> I use this for the fsck for ext4, and the nice thing is that even with
> a stripped binary.
>
> For example:

Yes, that is nice.

> https://github.com/tytso/e2fsprogs/blob/master/e2fsck/sigcatcher.c#L379

Thanks, I've made a note.

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?

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: Conditions, AKA exceptions.
  2023-03-12 10:44           ` Ralph Corderoy
@ 2023-03-12 16:46             ` Paul Winalski
  2023-03-12 16:53               ` Larry McVoy
  0 siblings, 1 reply; 21+ messages in thread
From: Paul Winalski @ 2023-03-12 16:46 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: coff

On 3/12/23, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
>
> 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?

I hate it when that happens.  Even worse is when adding the write(2)
with compile-time memory allocations makes the bug go away.  I once
had to spend three days camped out in someone's office debugging a
compiler crash.  The crash only happened 4 hours into a massive
multi-file compilation, and this guy's login session was the only one
where the problem reproduced under the debugger.  Heisenbugs are hell.

-Paul W.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: Conditions, AKA exceptions.
  2023-03-12 16:46             ` Paul Winalski
@ 2023-03-12 16:53               ` Larry McVoy
  0 siblings, 0 replies; 21+ messages in thread
From: Larry McVoy @ 2023-03-12 16:53 UTC (permalink / raw)
  To: Paul Winalski; +Cc: coff

On Sun, Mar 12, 2023 at 12:46:40PM -0400, Paul Winalski wrote:
> On 3/12/23, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
> >
> > 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?
> 
> I hate it when that happens.  Even worse is when adding the write(2)
> with compile-time memory allocations makes the bug go away.  I once
> had to spend three days camped out in someone's office debugging a
> compiler crash.  The crash only happened 4 hours into a massive
> multi-file compilation, and this guy's login session was the only one
> where the problem reproduced under the debugger.  Heisenbugs are hell.

I had one like that.  Sometimes, rarely, suninstall would throw a

	panic(psig)

which meant that someone in the kernel had messed with the process'
signal mask, which is a no-no.

Turns out that the SCSI twins had heard that people were interrupting
suninstall if it took too long, so under certain conditions, the SCSI
tape driver would disable SIGINT.

It was (obviously) my fault because I was doing POSIX conformance and
I was the last person in many kernel files.

Took me a long time to track that one down.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Conditions, AKA exceptions.
  2023-03-10 19:57         ` Marshall Conover
@ 2023-03-13 16:47           ` Ralph Corderoy
  2023-03-13 17:10             ` [COFF] " Paul Winalski
  0 siblings, 1 reply; 21+ messages in thread
From: Ralph Corderoy @ 2023-03-13 16:47 UTC (permalink / raw)
  To: coff

Hi Marshall,

> 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.

Thanks, it was a long read but enjoyable.

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

I'm not a fan either.  The exceptions Joe introduces above are more of a
simpler syntax for handling return codes.  He gives the expanded
equivalent at one point.

I also liked his enthusiam for ‘abandonment’, similar to a BUG() macro.

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: Conditions, AKA exceptions.
  2023-03-13 16:47           ` [COFF] Conditions, AKA exceptions Ralph Corderoy
@ 2023-03-13 17:10             ` Paul Winalski
  2023-03-13 21:12               ` Dave Horsfall
  0 siblings, 1 reply; 21+ messages in thread
From: Paul Winalski @ 2023-03-13 17:10 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: coff

On 3/13/23, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
>
>> That said, I absolutely loathe exceptions with all my heart.
>
> I'm not a fan either.

Exceptions play merry hell with compiler optimizations.  If you are in
a piece of code where an exception can occur, unless you have
knowledge of the global side-effects of the handler(s) that might get
invoked you must abandon any attempts to do data flow analysis of
global data items.

The C++ Standard Library is fond of using throw and catch exception
handling.  An optimizing compiler pretty much has to throw all data
flow optimization involving global variables, or things passed to a
callee by pointer, if anything in the call chain calls a C++ Standard
Library routine.

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.

-Paul W.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: Conditions, AKA exceptions.
  2023-03-13 17:10             ` [COFF] " Paul Winalski
@ 2023-03-13 21:12               ` Dave Horsfall
  0 siblings, 0 replies; 21+ messages in thread
From: Dave Horsfall @ 2023-03-13 21:12 UTC (permalink / raw)
  To: Computer Old Farts Followers

On Mon, 13 Mar 2023, Paul Winalski wrote:

> 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.

.sig!  .sig!

-- Dave

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
  2023-03-10 14:20   ` Larry Stewart
@ 2023-03-10 18:09     ` Steffen Nurpmeso
  0 siblings, 0 replies; 21+ messages in thread
From: Steffen Nurpmeso @ 2023-03-10 18:09 UTC (permalink / raw)
  To: Larry Stewart; +Cc: coff

Larry Stewart wrote in
 <498576F7-6881-4176-B187-F4ACB0A42F76@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)

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
       [not found] ` <20230310131512.891A8212A8@orac.inputplus.co.uk>
  2023-03-10 14:20   ` Larry Stewart
@ 2023-03-10 17:34   ` Warner Losh
  1 sibling, 0 replies; 21+ messages in thread
From: Warner Losh @ 2023-03-10 17:34 UTC (permalink / raw)
  To: coff

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

On Fri, Mar 10, 2023 at 6:15 AM Ralph Corderoy <ralph@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.
>

Exception handling is a great leap sideways. it's a supercharged goto with
steroids on top. In some ways more constrained, in other ways more prone to
abuse.

Example:

I diagnosed performance problems in a program that would call into
'waiting' threads that would read data from a pipe and then queue work.
Easy, simple, straightforward design. Except they used exceptions to then
process the packets rather than having a proper lockless producer /
consumer queue.

Exceptions are great for keeping the code linear and ignoring error
conditions logically, but still having them handled "somewhere" above the
current code and writing the code such that when it gets an abort, partial
work is cleaned up and trashed.

Global exception handlers are both good and bad. All errors become
tracebacks to where it occurred. People often don't disambiguate between
expected and unexpected exceptions, so programming errors get lumped in
with remote devices committing protocol errors get lumped in with your
config file had a typo and /dve/ttyU2 doesn't exist. It can be hard for the
user to know what comes next when it's all jumbled together. In-line error
handling, at least, can catch the expected things and give a more
reasonable error near to where it happened so I know if my next step is vi
prog.conf or email support@prog.com.

So it's a hate hate relationship with both. What do I hate the least?
That's a three drink minimum for the answer.

Warner

[-- Attachment #2: Type: text/html, Size: 2368 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
       [not found] ` <20230310131512.891A8212A8@orac.inputplus.co.uk>
@ 2023-03-10 14:20   ` Larry Stewart
  2023-03-10 18:09     ` Steffen Nurpmeso
  2023-03-10 17:34   ` Warner Losh
  1 sibling, 1 reply; 21+ messages in thread
From: Larry Stewart @ 2023-03-10 14:20 UTC (permalink / raw)
  To: coff

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@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.


^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2023-03-13 21:13 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-10 17:11 [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Bakul Shah
2023-03-10 17:28 ` segaloco via COFF
2023-03-10 17:34   ` Larry McVoy
2023-03-10 17:35   ` Bakul Shah
2023-03-10 17:42     ` Larry McVoy
2023-03-11 11:28       ` [COFF] Conditions, AKA exceptions Ralph Corderoy
2023-03-12  4:23         ` [COFF] " Theodore Ts'o
2023-03-12 10:44           ` Ralph Corderoy
2023-03-12 16:46             ` Paul Winalski
2023-03-12 16:53               ` Larry McVoy
2023-03-10 17:43     ` [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) segaloco via COFF
2023-03-10 18:03     ` Dan Cross
2023-03-10 18:57       ` Bakul Shah
2023-03-10 19:57         ` Marshall Conover
2023-03-13 16:47           ` [COFF] Conditions, AKA exceptions Ralph Corderoy
2023-03-13 17:10             ` [COFF] " Paul Winalski
2023-03-13 21:12               ` Dave Horsfall
2023-03-10 17:47   ` [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Bakul Shah
     [not found] <20230310121550.9A80718C080@mercury.lcs.mit.edu>
     [not found] ` <20230310131512.891A8212A8@orac.inputplus.co.uk>
2023-03-10 14:20   ` Larry Stewart
2023-03-10 18:09     ` Steffen Nurpmeso
2023-03-10 17:34   ` Warner Losh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).