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 19502 invoked from network); 10 Mar 2023 17:11:44 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 10 Mar 2023 17:11:44 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 2C05941579; Sat, 11 Mar 2023 03:11:42 +1000 (AEST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by minnie.tuhs.org (Postfix) with ESMTPS id 889A541575 for ; Sat, 11 Mar 2023 03:11:37 +1000 (AEST) Received: by mail-pj1-x102d.google.com with SMTP id p3-20020a17090ad30300b0023a1cd5065fso5834564pju.0 for ; Fri, 10 Mar 2023 09:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; t=1678468297; h=to:cc:date:message-id:subject:mime-version:from :content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=g/PNikSMWsThLljMgK1nPouyzjGfvWFgWU0LxBZOCrE=; b=AKZL/2mvV2h/tUszHOSAxQzbbQ1cnQb4qXd6WPee6K0il7mgn22d6GS5inBr1wVWfK +OMuiBSp0VjzlR4ueWlQI5UQlPMj5sJ1cLHkjBUV4aVptQ9QOKpcBbRHnjAvxTJqOPUj Rb3nEfjz+zJZCaXqozo3iuDrY19fyI93CGfljcMZlKoK+UuhYNDzEr9qZi2oZ2lblVhQ D2IDM5x+tecEW3pSLarOVocMgTn7C5CC4s4+V1FMFkOPRYd2M47/vLYSVN08wLIdYMjw kRdVDNKBllK7uu0PxVgr1wFK2v7ViLOmZOaUq22+yE8tz5659KosYiSAIrPPZa7GpC1V WuVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678468297; h=to:cc:date:message-id:subject:mime-version:from :content-transfer-encoding:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=g/PNikSMWsThLljMgK1nPouyzjGfvWFgWU0LxBZOCrE=; b=0aaQLnYiNXH49xQAoM8tu2bx342J6ZL9ZXPRqm6kgQEs0unEpPEYIhYL0Nt8P/WWjI voiUji1uOLWhg0O71CdChLRfHX36a8XB4IIKkCga4jFteMnQKml4UXOTFr/blw+YX72z E3XqEe910F59ckzOOkDtJL4YiuxxOcGRE5yfmyGtGs/72fG3dlUryhJtsvB0ho0rFwAD A1ybZUDqhgr4q7mNlq7f4mXKc4GW7qYTSYwJt72bQ7cRtxMeWdCnqRGDL9AjhN2HUUKS OQjpafjaeSqH3E+syzKZ8C3qzv3OcJensQwGPuOW6Z/XZ99lnNy+WNCwjAp9Zs/CJcLg wTzA== X-Gm-Message-State: AO0yUKW5OqgbOOTEg1JWcCRmIO2Ipj93TQUN4PmHtq4/EnZdB5soe2Iv 7ujIklrUlZoEd3YZInPvINeug4Vs+ZNVSBfXMyk= X-Google-Smtp-Source: AK7set+ShmUAnfB/ifsq5l0mBoBQ+JR+Nju1D9OYkZmTSvTA/Y1hiSxuwOOXGD5UIOT/rwJqwJjHxw== X-Received: by 2002:a17:902:aa84:b0:19e:76c2:c62 with SMTP id d4-20020a170902aa8400b0019e76c20c62mr22381428plr.15.1678468296774; Fri, 10 Mar 2023 09:11:36 -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 la14-20020a170902fa0e00b0019ee5e203d8sm237175plb.227.2023.03.10.09.11.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Mar 2023 09:11:36 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-B045E7C5-F148-4412-B05D-E9D93C1AA757 Content-Transfer-Encoding: 7bit From: Bakul Shah Mime-Version: 1.0 (1.0) Message-Id: <445734B5-EFA3-4224-8ABE-81D35A4D9CEC@iitbombay.org> Date: Fri, 10 Mar 2023 09:11:25 -0800 To: Larry Stewart X-Mailer: iPad Mail (20D67) Message-ID-Hash: MVVEWPV46WK5HBLO3GEDQBELB2PMKZFH X-Message-ID-Hash: MVVEWPV46WK5HBLO3GEDQBELB2PMKZFH 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-B045E7C5-F148-4412-B05D-E9D93C1AA757 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =EF=BB=BFTo make exceptional handling robust, I think every exception needs t= o be explicitly handled somewhere. If an exception not handled by a function= , that fact must be specified in the function declaration. In effect the com= piler can check that every exception has a handler somewhere. I think you ca= n implement it using different syntactic sugar than Go=E2=80=99s obnoxious e= rror handling but basically the same (though you may be tempted to make more= efficient). > On Mar 10, 2023, at 6:21 AM, Larry Stewart wrote: > =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 Lang= uages" and fully embraced exceptions. >=20 > The problem is that it is extremely tempting for the author of a library t= o use them, and equally tempting for the authors of library calls used by th= e 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 address s= pace, since there was no VM. In 1982 or so I set out to write a shell for i= t, 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 exce= ption they could raise. >=20 > This was an immensely frustrating process because while the language sugge= sted that the author of a library capture exceptions on the way by and trans= late them to one at the package level, this is a terrible idea in its own wa= y, 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.= >=20 > Another thing that happens with exceptions is that programmers get the bri= ght 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= . >=20 > On the whole, I came away with a great deal of grudging respect for ERRNO a= s 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 progr= ammer's job to sort exceptional conditions into actionable categories: (1) r= esolvable by the user (bad arguments) (2) Temporary (out of network sockets o= r whatever) (3) resolvable by the sysadmin (config) (4) real bug, resolvable= 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 wrote= : >>=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 >>> 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. --Apple-Mail-B045E7C5-F148-4412-B05D-E9D93C1AA757 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=EF=BB=BFTo make exception= al handling robust, I think every exception needs to be explicitly handled s= omewhere. If an exception not handled by a function, that fact must be s= pecified in the function declaration. In effect the compiler can check that e= very exception has a handler somewhere. I think you can implement it using d= ifferent syntactic sugar than Go=E2=80=99s obnoxious error handling but basi= cally the same (though you may be tempted to make more efficient).
 On Mar 10, 2023, at 6:21 A= M, Larry Stewart <stewart@serissa.com> wrote:

=EF=BB=BFTLDR exceptions d= on't make it better, they make it different.

The Mesa and Cedar languages at PARC CSL were intended to be "Systems Lang= uages" and fully embraced exceptions.

The p= roblem is that it is extremely tempting for the author of a library to use t= hem, and equally tempting for the authors of library calls used by the first= library, and so on.
At the application level, literally any= thing can happen on any call.

The Cedar OS w= as a library OS, where applications ran in the same address space, since the= re 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 frustra= ting process because while the language suggested that the author of a libra= ry 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 - th= e state of the ultimate problem was lost.  So no one did this, and at t= he top level, literally any exception could occur.
Another thing that happens with exceptions is that programmers get t= he bright idea to use them for conditions which are uncommon, but expected, s= o any user of the function has to write complicated code to deal with these c= ases.

On the whole, I came away with a grea= t deal of grudging respect for ERRNO as striking a great balance between eas= e of use and specificity.

I also evolved La= rry's Theory of Exceptions, which is that it is the programmer's job to sort= exceptional conditions into actionable categories: (1) resolvable by the us= er (bad arguments) (2) Temporary (out of network sockets or whatever) (3) re= solvable by the sysadmin (config) (4) real bug, resolvable by the author.

The usual practice of course is the popup "Re= ceived unknown error, OK?"

-Larry
On Mar 10, 2023, at 8:15 A= M, Ralph Corderoy <ralph@inputplus.co.uk> wrote:

=EF=BB=BFHi Noel,

if you say above that most people a= re unfamiliar with them due to
their use of goto then that's probably wrong

<= blockquote type=3D"cite">I didn't say that.

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

I was just as= tonished 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 got= os also tend to be those who dislike
exceptions.  :-)

Any= way, I'm off-TUHS-pic so follow-ups set to goto COFF.

--
Chee= rs, Ralph.

= = --Apple-Mail-B045E7C5-F148-4412-B05D-E9D93C1AA757--