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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22422 invoked from network); 10 Mar 2023 17:35:18 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 10 Mar 2023 17:35:18 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 200B541581; Sat, 11 Mar 2023 03:35:17 +1000 (AEST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by minnie.tuhs.org (Postfix) with ESMTPS id 1C8FC41579 for ; Sat, 11 Mar 2023 03:35:11 +1000 (AEST) Received: by mail-ed1-x531.google.com with SMTP id s11so23501833edy.8 for ; Fri, 10 Mar 2023 09:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; t=1678469709; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=nNIPm3oa+zL60Bxfr5dQTiyvD6TeTcwJGNWj8a56gYY=; b=EXIt2iqvQ9Qht6YeR69CNAWCsnJGL5p9C5+SRmLVDrIDbWT4Ra7TpOYhs7n73D3AO2 bgJ5f6eV0Af33qqgTsx3bNCPx7pvNdrZ+U+jZoGenF+i2AsywYd6lMNmxb9YSmro0cbk vasiq27OhkfYJjg5knpZxrdNdHYXXRXKgnt/fhVQHdlgwPBQnyT8P7cxiV4fj8lmfreZ X9AQIaEEPlM4oUJcDRmk/7aTVc4fU59cYq5dusP0YBEALFjUdfZy9c394RlWqGWeSHRA 5Sq/hshGuWg3/XR4z7lR4EMP+tHN/IRkrpaIHds1+ZI7wFC1/N1vZC9ySF/ZFAbW+oMK DfvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678469709; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nNIPm3oa+zL60Bxfr5dQTiyvD6TeTcwJGNWj8a56gYY=; b=sACT320Ok3NVX6s4+gYr9ITAhuGosgsd2kIbqSMTQDR3gq63UQnOEgZSpKinD5VSwJ NfVwFQJEUv4A5EWAMOnzlHHV96UNKi9oJ37BEuhLL+dfZ4bu4mVEXdeL2PZf7gF2a2ZP f48o5UqZXrc2vlOrVgA7Knrk0zi7dA3wa54R4vgi6DRB6WLiCmnczgJWoSJYlJmLbcEi eDO1m1PzPmZbdoBdoruCGBfgtOmrzSMcQwAP1r4hgxSko0WlQlxyDNWgwaE92k3HnFce VzAkAqGxMAZdqOpLQUZMHpJVb+sB52hXpYww/BVtuzoypR12mhmlGOrkURXVAHtoAnju zvaw== X-Gm-Message-State: AO0yUKWkfGBZ28qDbwFA7paNWD26JznrnWd+8KloKJFTWdW86sUCgtBt soDA3cUyuAxfOM395iC2sKbXsgRI2rp3KqoeUx0Q02bqgO0Dszmi X-Google-Smtp-Source: AK7set8D49j37f/c5dloldVKHd2TKEwRDM4CjxbiuwOI7p2QpbUhPBzseNsPNBnIEyWMn8ADQej4tqEdB6F2GcZfie0= X-Received: by 2002:a50:c355:0:b0:4ae:e606:432f with SMTP id q21-20020a50c355000000b004aee606432fmr14716005edb.0.1678469708858; Fri, 10 Mar 2023 09:35:08 -0800 (PST) MIME-Version: 1.0 References: <20230310121550.9A80718C080@mercury.lcs.mit.edu> <20230310131512.891A8212A8@orac.inputplus.co.uk> In-Reply-To: <20230310131512.891A8212A8@orac.inputplus.co.uk> From: Warner Losh Date: Fri, 10 Mar 2023 10:34:57 -0700 Message-ID: To: coff@tuhs.org Content-Type: multipart/alternative; boundary="000000000000c358ae05f68f2e56" Message-ID-Hash: KYAWAXK4FFEGK2WCB6ZMQ26POUPBXNHS X-Message-ID-Hash: KYAWAXK4FFEGK2WCB6ZMQ26POUPBXNHS X-MailFrom: wlosh@bsdimp.com 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 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: --000000000000c358ae05f68f2e56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 10, 2023 at 6:15=E2=80=AFAM Ralph Corderoy 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 --000000000000c358ae05f68f2e56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 10, 2023 at 6:15=E2=80=AF= AM Ralph Corderoy <ralph@inputp= lus.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 su= percharged goto with steroids on top. In some ways more constrained, in oth= er 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 qu= eue 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 c= ode 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 err= ors 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 c= an be hard for the user to know what comes next when it's all jumbled t= ogether. In-line error handling, at least, can catch the expected things an= d give a more reasonable error near to where it happened so I know if my ne= xt step is vi prog.conf or email suppor= t@prog.com.

So it's a hate hate relationsh= ip with both. What do I hate the least? That's a three drink minimum fo= r the answer.

Warner
--000000000000c358ae05f68f2e56--