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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4696 invoked from network); 10 Mar 2023 19:36:17 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 10 Mar 2023 19:36:17 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 72CDB41596; Sat, 11 Mar 2023 05:36:12 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1678476972; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=ZNu5kvGkc5KrhDE+uzl6ZIlvymYE10jskPqg/e8cVWU=; b=VTtiHlp2bWOpkU8b1HuMh7Zx5P4XrDpg+uQUNYbqoXV+NtdGq4cYQwpfDgXGhJ4C2wxPUl BnZABfpyT/KaL5AxO/hUNenAG4bPQHyKIBxCv94Xzla0sSJvjqoksez4hfCMcOCGTdX93M lwv+gd48U4OAydW+aDmy/hSMkyqjzmw= Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by minnie.tuhs.org (Postfix) with ESMTPS id F287141585 for ; Sat, 11 Mar 2023 05:36:05 +1000 (AEST) Date: Fri, 10 Mar 2023 19:35:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1678476963; x=1678736163; bh=ZNu5kvGkc5KrhDE+uzl6ZIlvymYE10jskPqg/e8cVWU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=gE5tz//oZ9MFsm9aY/N3kNxhtEzBJklQKGPbvG0NSpVK7mUhMoNqy01aBWfElDrVx 0zf7CTmNCFJhYayM+jfvGsYw9Y4tpoANYxx5zR/Cp4FxuiHUIowtZwzcwfYhkrUAoc skzZOeNrF6U16AYcXyCfJzdlPb+ubX0yDqK44BJUMB9DuT2X1M4IO69N7eg46u+Qk4 IZAi242PSXypBmLogoO4V8wG2oXBPOdwBcu6KTy+4Espy7L0Qq8kpH0C6o9l1hnLf0 oACXujwcbGuBudNA8sOAq5Ce0ot67iD5VmNo4fHY2DVmumHfRGPG+ySVc+id6a9sAl /mM6YYeYs359w== To: Dan Cross Message-ID: In-Reply-To: References: <20230310153702.AFF3418C080@mercury.lcs.mit.edu> Feedback-ID: 35591162:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: TUDMUSYROOXUN262VU5HFFWHLDTN6RKY X-Message-ID-Hash: TUDMUSYROOXUN262VU5HFFWHLDTN6RKY X-MailFrom: segaloco@protonmail.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 CC: Noel Chiappa , tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: segaloco via TUHS Reply-To: segaloco 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 c= ould 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 wrote= : > On Fri, Mar 10, 2023 at 1:55=E2=80=AFPM Ron Natalie ron@ronnatalie.com wr= ote: >=20 > > That=E2=80=99s my point. Both break structure. > >=20 > > Just hinding the break with some construct that isn=E2=80=99t =E2=80= =9Cgoto=E2=80=9D doesn=E2=80=99t > > make it acceptable. >=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > - Dan C.