The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: segaloco via TUHS <tuhs@tuhs.org>
To: Dan Cross <crossd@gmail.com>
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>, tuhs@tuhs.org
Subject: [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
Date: Fri, 10 Mar 2023 19:35:50 +0000	[thread overview]
Message-ID: <qxkBdvBiUAjmAA9pLcJAp-kXs78lS5rJ5YSV93SBZ-IapR3UlYYkM5EfMIorn6PSNcMQCIch2PWgKzy_g35rwkgGdj912yvBRFWjapQsUFY=@protonmail.com> (raw)
In-Reply-To: <CAEoi9W57RBzyfYeY2Gvqjh0i1z=FsaS3rT5i7oSNdSEADVd5CA@mail.gmail.com>

That's a good point about the specifics, there's no one-size-fits-all error condition that describes every possible exceptional circumstance, so how could there be one singular best practice for handling the abstract concept of an "error".

Plus, given one person's error is another person's business logic sometimes...if we can't agree on what an error is, how can a computer be expected to :P

- Matt G.

------- Original Message -------
On Friday, March 10th, 2023 at 11:04 AM, Dan Cross <crossd@gmail.com> wrote:


> On Fri, Mar 10, 2023 at 1:55 PM Ron Natalie ron@ronnatalie.com wrote:
> 
> > That’s my point. Both break structure.
> > 
> > Just hinding the break with some construct that isn’t “goto” doesn’t
> > make it acceptable.
> 
> 
> The alternative is often worse, though. I'd take a well-aimed goto or
> a nested break over a bunch of conditionals in the bodies of loops any
> day, both in terms of readability and performance.
> 
> That said, I'm not a huge fan of the `goto fail;` pattern. Apple had a
> pretty major bug with that, and I find that many, many times it can be
> replaced with a restructuring of the code. For example, perhaps do
> your allocation, call a function and capture the return value (passing
> the allocated resources as arguments), and then de-allocate and return
> the cached return value. Let the compiler optimize it.
> 
> As an experiment, I rewrote the Apple bug code (which was open source)
> to do that and it was cleaner and simpler than the original. Someone I
> showed it to said, "but what, are you going to do that for every
> function that can fail?" Well no, but generally you don't have to; we
> fixate too much on the general problem and ignore the specifics.
> 
> - Dan C.

  reply	other threads:[~2023-03-10 19:36 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10 15:37 Noel Chiappa
2023-03-10 15:46 ` Larry McVoy
2023-03-10 16:04 ` Dan Cross
2023-03-10 18:55 ` Ron Natalie
2023-03-10 19:04   ` Dan Cross
2023-03-10 19:35     ` segaloco via TUHS [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-03-10 11:51 Noel Chiappa
2023-03-10 14:16 ` Ronald Natalie
2023-03-10 14:39   ` John Cowan
2023-03-10 16:30   ` Phil Budne
2023-03-10 17:50     ` Steffen Nurpmeso
2023-03-10 17:57       ` Paul Winalski
2023-03-10 18:12         ` Lawrence Stewart
2023-03-10 17:28   ` Clem Cole
2023-03-10 17:54     ` Paul Winalski
2023-03-10 11:37 Noel Chiappa
2023-03-10 15:54 ` Dan Cross
2023-03-12  7:39   ` Anthony Martin
2023-03-12 11:40     ` Dan Cross
2023-03-12 16:40       ` Paul Winalski
2023-03-13  3:25       ` John Cowan
2023-03-13 10:40         ` Alejandro Colomar (man-pages)
2023-03-13 12:19           ` Dan Cross
2023-03-09 23:01 [TUHS] " Steffen Nurpmeso
2023-03-09 23:18 ` [TUHS] " segaloco via TUHS
2023-03-09 23:21   ` Warner Losh
2023-03-09 23:31     ` Luther Johnson
2023-03-09 23:44       ` josh
2023-03-09 23:54       ` Warner Losh
2023-03-10  0:54         ` segaloco via TUHS
2023-03-10  1:08           ` Warner Losh
2023-03-10 10:08             ` Ralph Corderoy
2023-03-10 11:37               ` arnold
2023-03-10 11:56                 ` Ralph Corderoy
2023-03-10 11:59                   ` arnold
2023-03-10 12:11                     ` Ralph Corderoy
2023-03-10  6:15     ` Dave Horsfall
2023-03-10 16:55       ` Steffen Nurpmeso
2023-03-10 17:02         ` Bakul Shah
2023-03-12 20:47         ` Dave Horsfall
2023-03-12 21:50           ` Warner Losh
2023-03-12 22:27             ` Steffen Nurpmeso
2023-03-10  1:31   ` Rich Morin

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='qxkBdvBiUAjmAA9pLcJAp-kXs78lS5rJ5YSV93SBZ-IapR3UlYYkM5EfMIorn6PSNcMQCIch2PWgKzy_g35rwkgGdj912yvBRFWjapQsUFY=@protonmail.com' \
    --to=tuhs@tuhs.org \
    --cc=crossd@gmail.com \
    --cc=jnc@mercury.lcs.mit.edu \
    --cc=segaloco@protonmail.com \
    /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).