From: Warner Losh <imp@bsdimp.com>
To: coff@tuhs.org
Subject: [COFF] Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
Date: Fri, 10 Mar 2023 10:34:57 -0700 [thread overview]
Message-ID: <CANCZdfob3HM34_t2OjGqUbt-p6LEQfbWDQ6-Ttc0O0tL=6dWog@mail.gmail.com> (raw)
In-Reply-To: <20230310131512.891A8212A8@orac.inputplus.co.uk>
[-- 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 --]
next prev parent reply other threads:[~2023-03-10 17:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 message]
2023-03-10 17:11 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-10 17:43 ` 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-10 17:47 ` Bakul Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANCZdfob3HM34_t2OjGqUbt-p6LEQfbWDQ6-Ttc0O0tL=6dWog@mail.gmail.com' \
--to=imp@bsdimp.com \
--cc=coff@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).