From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,MIME_QP_LONG_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22523 invoked from network); 10 Mar 2023 17:36:01 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 10 Mar 2023 17:36:01 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 9651141581; Sat, 11 Mar 2023 03:36:00 +1000 (AEST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by minnie.tuhs.org (Postfix) with ESMTPS id 2150341579 for ; Sat, 11 Mar 2023 03:35:56 +1000 (AEST) Received: by mail-pl1-x62f.google.com with SMTP id v11so6361101plz.8 for ; Fri, 10 Mar 2023 09:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; t=1678469755; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=M9m5B5CL14FgZsILT3e6oSB3xwL26MlI+SLPQN6B/Mw=; b=ZpeCskTygR/8YaxwDsj5p7dPjL/8JQBxUyvBDHzu4IMd0/+EquX4lI47NnSYkgxB53 tQTDpEq35RkbPZk8IaVNR8NLc2MyjL3B8vh406fVLpl7eMh/cJgPtYv0rEHrwr8CwXad BgBqXwIDssX4+XXD5/bW+xuLPJ+G5OD0vkR3F8fQfPoxQddxgZckhBeROc57wRvyznea Onuf5zzrBt5VekvuLXPAKSy0dFBVoAT1HWKx3omyThO7QmPJ+2rZyZcPMi8Vh2wQ+PdW RAXTTYMK/XH4iXpyNjoF0aFSIWpB/RGqwSwwR6Us7iOS0IdEtmWe/HVVYaw99/eCWsbA /h4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678469755; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=M9m5B5CL14FgZsILT3e6oSB3xwL26MlI+SLPQN6B/Mw=; b=qTFdL7YfNzqJCgMHX0mGPbEC0yO9fq8DZ73DqN/V/1uW3lLPDYX0GKRxQCaHqGvApK HQMemTL8hRDpYPzJIPfSJwYEjJG3RjCCTeOd3goFFzg9u89oXa6+HyVF9opCmEILtr7N NNpSY6i8rICDyJa99SLLg0Wl7gCnWjWe+4/XzmkDNux1JOy8PLDEkDFfZ27i94LS8Tqa ULhaFxsjs2MaUSDrFMb7+uAQc8J2YuAUQQiCOLLPlN3iuNerfDzijYRUyfkJYHdCsk2f zOP7Xqq9UyS086bUp74kME92189ILEA4HF6bkLdgMHiL/dgNowYCgcFrsY/+Itxq27Oq IKuA== X-Gm-Message-State: AO0yUKUXkBZjMPpkDJpE7bBfLmOKHto6FxbcffYwMIX/VSejoOjLkUW2 V09zvJYQmldgl48m/Fufsl+BBQ== X-Google-Smtp-Source: AK7set+Q/hrv2an5FM7bwohj/o1UpUZUnR/KVRe6iovw3TERhqq8BSdTtbnfmEOpIdi8ebDpKw5piw== X-Received: by 2002:a17:90b:3a88:b0:237:b702:4958 with SMTP id om8-20020a17090b3a8800b00237b7024958mr27284165pjb.38.1678469755248; Fri, 10 Mar 2023 09:35:55 -0800 (PST) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id 26-20020a17090a035a00b0023377b98c7csm201456pjf.38.2023.03.10.09.35.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Mar 2023 09:35:54 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-55B336EF-1819-4B87-8EA7-A2242A6964F9 Content-Transfer-Encoding: 7bit From: Bakul Shah Mime-Version: 1.0 (1.0) Date: Fri, 10 Mar 2023 09:35:44 -0800 Message-Id: <69248852-1701-4938-8A4D-3B27F3018E83@iitbombay.org> References: In-Reply-To: To: segaloco X-Mailer: iPad Mail (20D67) Message-ID-Hash: E2NUERKUWFMW6DUAWDCLBQOWTJHALQBC X-Message-ID-Hash: E2NUERKUWFMW6DUAWDCLBQOWTJHALQBC X-MailFrom: bakul@iitbombay.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: coff@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail-55B336EF-1819-4B87-8EA7-A2242A6964F9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable During development the runtime should simply invoke a debugger in this case.= This should be perfectly doable but for some reason it is considered accept= able to crash a program! I don=E2=80=99t want to run a program *under a debu= gger* but want it invoked at the right time! > On Mar 10, 2023, at 9:28 AM, segaloco wrote: >=20 > =EF=BB=BF > 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 ign= ore their exception/condition handling and hard-crash. Of course you don't w= ant to take that kind of hammer to a production situation, but a way to over= ride any and all handling so that real errors become apparent would be incre= dibly nice. >=20 > 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 su= ch a thing exists in C# but I've never gone looking for it, all I know is ca= tching an exception from some vendor library with zero useful information ma= kes me want to take a hammer to much more than the code... >=20 > - Matt G. > ------- Original Message ------- > On Friday, March 10th, 2023 at 9:11 AM, Bakul Shah w= rote: >=20 >> =EF=BB=BFTo make exceptional handling robust, I think every exception nee= ds to be explicitly handled somewhere. If an exception not handled by a func= tion, that fact must be specified in the function declaration. In effect the= compiler can check that every exception has a handler somewhere. I think yo= u can implement it using different syntactic sugar than Go=E2=80=99s obnoxio= us error handling but basically the same (though you may be tempted to make m= ore efficient). >>=20 >>> On Mar 10, 2023, at 6:21 AM, Larry Stewart wrote:= >>>=20 >>> =EF=BB=BFTLDR exceptions don't make it better, they make it different. >>>=20 >>> The Mesa and Cedar languages at PARC CSL were intended to be "Systems La= nguages" and fully embraced exceptions. >>>=20 >>> 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 t= he first library, and so on. >>> At the application level, literally anything can happen on any call. >>>=20 >>> The Cedar OS was a library OS, where applications ran in the same addres= s space, since there was no VM. In 1982 or so I set out to write a shell fo= r it, and was determined that regardless of what happened, the shell should n= ot crash, so I set out to guard every single call with handlers for every ex= ception they could raise. >>>=20 >>> This was an immensely frustrating process because while the language sug= gested that the author of a library capture exceptions on the way by and tra= nslate them to one at the package level, this is a terrible idea in its own w= ay, because you can't debug - the state of the ultimate problem was lost. S= o no one did this, and at the top level, literally any exception could occur= . >>>=20 >>> Another thing that happens with exceptions is that programmers get the b= right idea to use them for conditions which are uncommon, but expected, so a= ny user of the function has to write complicated code to deal with these cas= es. >>>=20 >>> On the whole, I came away with a great deal of grudging respect for ERRN= O as striking a great balance between ease of use and specificity. >>>=20 >>> I also evolved Larry's Theory of Exceptions, which is that it is the pro= grammer's job to sort exceptional conditions into actionable categories: (1)= resolvable by the user (bad arguments) (2) Temporary (out of network socket= s or whatever) (3) resolvable by the sysadmin (config) (4) real bug, resolva= ble by the author. >>>=20 >>> The usual practice of course is the popup "Received unknown error, OK?" >>>=20 >>> -Larry >>>=20 >>>> On Mar 10, 2023, at 8:15 AM, Ralph Corderoy wro= te: >>>>=20 >>>> =EF=BB=BFHi Noel, >>>>=20 >>>>>> if you say above that most people are unfamiliar with them due to >>>>>> their use of goto then that's probably wrong >>>>>=20 >>>>> I didn't say that. >>>>=20 >>>> Thanks for clarifying; I did know it was a possibility. >>>>=20 >>>>> 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. >>>>=20 >>>> Or perhaps those happy to use gotos also tend to be those who dislike >>>> exceptions. :-) >>>>=20 >>>> Anyway, I'm off-TUHS-pic so follow-ups set to goto COFF. >>>>=20 >>>> --=20 >>>> Cheers, Ralph. >>>=20 >=20 --Apple-Mail-55B336EF-1819-4B87-8EA7-A2242A6964F9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dur= ing development the runtime should simply invoke a debugger in this case. Th= is should be perfectly doable but for some reason it is considered acceptabl= e to crash a program! I don=E2=80=99t want to run a program *under a debugge= r* but want it invoked at the right time!

On Mar 10, 2023, at 9:28 AM, segaloco <segaloco@protonm= ail.com> wrote:

=EF=BB=BF
On the flip side something I've always thought woul= d be powerful, at least in development, is a way to tell any and all procedu= res 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 situa= tion, but a way to override any and all handling so that real errors become a= pparent would be incredibly nice.

If nothing else, I= could provide much better stack traces to vendors when I'm particularly stu= ck on something and convinced it isn't my fault. Maybe such a thing exists i= n 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...

- Ma= tt G.
------- Original Message -------
On Friday, March 10th, 2023 at 9:11 AM, Bakul Shah <bakul@iitbomb= ay.org> wrote:

=EF=BB=BFTo make exceptional handling robust, I= think every exception needs to be explicitly handled somewhere. If an e= xception not handled by a function, that fact must be specified in the funct= ion declaration. In effect the compiler can check that every exception has a= handler somewhere. I think you can implement it using different syntactic s= ugar than Go=E2=80=99s obnoxious error handling but basically the same (thou= gh you may be tempted to make more efficient).

 On Mar 10, 2023, at 6:21 AM, Larry Stewart <= ;stewart@serissa.com> wrote:

=EF=BB=BFTLDR 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 emb= raced exceptions.

The problem is that it is= extremely tempting for the author of a library to use them, and equally tem= pting for the authors of library calls used by the first library, and so on.=
At the application level, literally anything can happen on a= ny call.

The Cedar OS was a library OS, whe= re 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 reg= ardless of what happened, the shell should not crash, so I set out to guard e= very single call with handlers for every exception they could raise.<= br>
This was an immensely frustrating process because w= hile the language suggested that the author of a library capture exceptions o= n the way by and translate them to one at the package level, this is a terri= ble 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 t= hat happens with exceptions is that programmers get the bright idea to use t= hem for conditions which are uncommon, but expected, so any user of the func= tion has to write complicated code to deal with these cases.

On the whole, I came away with a great deal of grudging re= spect for ERRNO as striking a great balance between ease of use and specific= ity.

I also evolved Larry's Theory of Excep= tions, which is that it is the programmer's job to sort exceptional conditio= ns into actionable categories: (1) resolvable by the user (bad arguments) (2= ) Temporary (out of network sockets or whatever) (3) resolvable by the sysad= min (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:

=EF=BB=BF= Hi Noel,

<= /blockquote>
if you say above that most people are unfamiliar with the= m due to
their use o= f goto then that's probably wrong

=
I didn't say that.

T= hanks for clarifying; I did know it was a possibility.

I was just astonished that in a long t= hread about handling exceptional
conditions, nobody had me= ntioned . . . exceptions.  Clearly, either
unfamiliar= ity (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
exceptio= ns.  :-)
=
Anyway, I'm off-TUHS-pic so= follow-ups set to goto COFF.

-- <= br>
Cheers, Ralph.


= --Apple-Mail-55B336EF-1819-4B87-8EA7-A2242A6964F9--