220 18484 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Thoughts on Exceptions, Expected, and Error Handling Date: Sun, 7 Jun 2015 01:24:27 -0700 (PDT) Lines: 174 Approved: news@gmane.org Message-ID: References: <1d83a5df-f8b1-41fc-a197-319825b5436d@isocpp.org> <97c9b3aa-44b4-4a63-92a0-a571628b0735@isocpp.org> <303e5cc6-8a3e-4063-880e-eac448ec0dc6@isocpp.org> <55729C6A.7020707@wanadoo.fr> <0243bdcb-c0a1-4343-88d6-caef3e962cbb@isocpp.org> <15865f86-48ec-4a5d-8917-c87dc60d9d51@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1114_307705209.1433665467962" X-Trace: ger.gmane.org 1433665473 20117 80.91.229.3 (7 Jun 2015 08:24:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Jun 2015 08:24:33 +0000 (UTC) Cc: mw_triad@users.sourceforge.net To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBPH7Z6VQKGQELORFR3Q@isocpp.org Sun Jun 07 10:24:33 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z1Vsc-0004oS-HQ for gclcip-std-proposals@m.gmane.org; Sun, 07 Jun 2015 10:24:30 +0200 Original-Received: by ierg5 with SMTP id g5sf71704789ier.2 for ; Sun, 07 Jun 2015 01:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=X/SQkqXqh6NoeTwupzC88dDKOPwY9q4m6nICLw4hR2k=; b=iNKvbTMJaG2ngNazhm5brcVzsnLC4+6Mjo8ZPEQ5C97IQRvRTsP6uuyTyRB2C8SQGC qQ0CnG+xaoXK/68V/xZjJAnIL1KotdeBuq2C788SMOpKzOIuYlXnVrLkM5WelVUndzaU m94Z5NCoLYRHCLfR/ANxYvv6FxzlHVtUvEKlbMEBHKEznRnP7qUipsjwm5jNWEFbRq62 vVlMj94gFDIGyu3odrRKoOTjURDy4m38KjQhFWCvbJ7xypNuYm8h1Dcn3qB2w9tGRVPE GIOEEV9y1fXQ196F3xztnR3Fwa4ExXQezSn3/TL857bNZTXWV4dvi08l84lh2lsIZA6Y zEFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=X/SQkqXqh6NoeTwupzC88dDKOPwY9q4m6nICLw4hR2k=; b=jnwyau9JXQAbD+U3ZfIrxD/w05YZ1buJZAMG5oz9etlw0fja1FMcqpgCy6U6DvLzum humCG5l6oEwqqdZWpdyYUm18VvojvjQynSNrtTxicj+YX/NI5ICc96+wYp8XtxZi9J94 V29leeMzIZ9pEluf4KZr/AJ/wtaZuntSYQ60WEmUAe2YfIJmAnyU8FfH6TFUMF4yYq7D wQX7kM1wForWzLt1kxpyulfp9uaG659x3Zrt338SLbDxo3ZmXitw5K4G8n9JXOnCSQJn fteZqbG4pkCuKPQy8c7Fl1IIiTMRKaCDwyL2d1Hty14Br1NoQ/cjtxMF2MDODfRYn4dv bh7g== X-Gm-Message-State: ALoCoQmpLFZPqO9XKNpmnPJd5C2H1iYAJrJ3ReSq4bcl2LOCqOIa1cB4qkR2bRUXGqENlp36ZVEu X-Received: by 10.50.142.39 with SMTP id rt7mr9707102igb.5.1433665469331; Sun, 07 Jun 2015 01:24:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.87.119 with SMTP id q110ls2315833qgd.90.gmail; Sun, 07 Jun 2015 01:24:28 -0700 (PDT) X-Received: by 10.140.39.165 with SMTP id v34mr132183qgv.25.1433665468614; Sun, 07 Jun 2015 01:24:28 -0700 (PDT) In-Reply-To: <15865f86-48ec-4a5d-8917-c87dc60d9d51@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:18484 Archived-At: ------=_Part_1114_307705209.1433665467962 Content-Type: multipart/alternative; boundary="----=_Part_1115_460825687.1433665467962" ------=_Part_1115_460825687.1433665467962 Content-Type: text/plain; charset=UTF-8 On Saturday, June 6, 2015 at 5:16:06 AM UTC-4, Sean Middleditch wrote: > > On Saturday, June 6, 2015 at 12:24:31 AM UTC-7, Nicol Bolas wrote: > The approach mentioned in previous posts were not brought up "because > functional languages do it." They're because the options presented for C++ > thus far are all inadequate for a significant portion of the primary > "customers" of the language. And that's frustrating because we _know_ it > can be better (if not perfect) as we have clear examples of better ways of > doing things. All one must do is look over at those dirty > functional-programmer hippies and pay attention for a few of them (hey, > many of them have exceptions _too_; turns out they're not all that > different from us!). > > There is a very huge difference between it being merely a possibility to > write code that dodges landmines rather than being strongly guided towards > writing code that is obvious, clear, and does exactly what it says upon > cursory inspection. > > Return codes make incidental mistakes (even for experienced experts) > easier than writing robust code. Exceptions make incidental screwups (even > for experienced experts) easier than writing robust code. BOTH methods > result in degraded productivity, poor user experiences, and lost profits. > Now, I'm starting to understand. You believe that C++ error handling, *of all kinds*, is fundamentally broken. And thus, the only way to fix it is to create an entirely new paradigm, along with a bunch of new syntactic stuff added on, which is based on stuff taken from functional programming. Because you think that functional error resolution is just awesome and works better than anything in C++. I believe that C++ error handling is quite good, but has some holes in it. `expected` plugs one of the biggest: allowing the user to request local error resolution for returned values, in a way that makes that as easy on the user to implement as possible. You want to turn `expected` into the one true way to handle errors. I've learned a lot in my years of programming. One of the most important lessons is this: never trust "the one true way" to do *anything*. "The one true way" led to things like iostream. To uniform initialization syntax that you can't use uniformly. And so forth. Just as there's no such thing as a free lunch, "the one true way" never is. Also, I'd love to see some evidence that "a significant portion of the primary 'customers' of the language" find exceptions and/or the current incarnation of `expected` to be "inadequate". That damage can't be undone, but we can stop willfully inflicting more of > it out of our own stubborn refusal to admit that C++ today is not the best > language, nor even the best C++. > > Now, certainly, the things I previously mentioned don't solve all > problems. I don't claim to be a genius with a perfect solution for every > problem. I was at least hoping to tap into the minds of other smart people > who might be willing to work through those problems and potential > solutions. Not what I'm going to get, apparently. > Of course not. Because we don't believe that error handling in C++ is fundamentally broken. You shouldn't expect other people to agree with such extreme positions. Or at least, not in any real quantity. We know - and have ample proof - that there are more options for handling > errors than just either return values or exceptions. Yet that's what every > discussion about error handling in C++ turns into: a choice between bad or > suboptimal. > .... `expected` *is a return value*. You want to call it something else, but that's what it is. -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_1115_460825687.1433665467962 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, June 6, 2015 at 5:16:06 AM UTC-4, Sean Middle= ditch wrote:
On Saturday, = June 6, 2015 at 12:24:31 AM UTC-7, Nicol Bolas wrote:
T= he approach mentioned in previous posts were not brought up "because functi= onal languages do it." They're because the options presented for C++ thus f= ar are all inadequate for a significant portion of the primary "customers" = of the language. And that's frustrating because we _know_ it can be better = (if not perfect) as we have clear examples of better ways of doing things. = All one must do is look over at those dirty functional-programmer hippies a= nd pay attention for a few of them (hey, many of them have exceptions _too_= ; turns out they're not all that different from us!).

Th= ere is a very huge difference between it being merely a possibility to writ= e code that dodges landmines rather than being strongly guided towards writ= ing code that is obvious, clear, and does exactly what it says upon cursory= inspection.

Return codes make incidental mistakes= (even for experienced experts) easier than writing robust code. Exceptions= make incidental screwups (even for experienced experts) easier than writin= g robust code. BOTH methods result in degraded productivity, poor user expe= riences, and lost profits.

Now, I'm starti= ng to understand.

You believe that C++ error handling, of all kin= ds, is fundamentally broken. And thus, the only way to fix it is to cre= ate an entirely new paradigm, along with a bunch of new syntactic stuff add= ed on, which is based on stuff taken from functional programming. Because y= ou think that functional error resolution is just awesome and works better = than anything in C++.

I believe that C++ error handling is quite goo= d, but has some holes in it. `expected` plugs one of the biggest: allowing = the user to request local error resolution for returned values, in a way th= at makes that as easy on the user to implement as possible.

You want= to turn `expected` into the one true way to handle errors.

I've lea= rned a lot in my years of programming. One of the most important lessons is= this: never trust "the one true way" to do anything. "The one true = way" led to things like iostream. To uniform initialization syntax that you= can't use uniformly. And so forth.

Just as there's no such thing as= a free lunch, "the one true way" never is.

Also, I'd love to see so= me evidence that "a significant portion of the primary 'customers' of the l= anguage" find exceptions and/or the current incarnation of `expected` to be= "inadequate".

That damage can't be undone, but we can stop= willfully inflicting more of it out of our own stubborn refusal to admit t= hat C++ today is not the best language, nor even the best C++.
Now, certainly, the things I previously mentioned don't solve = all problems. I don't claim to be a genius with a perfect solution for ever= y problem. I was at least hoping to tap into the minds of other smart peopl= e who might be willing to work through those problems and potential solutio= ns. Not what I'm going to get, apparently.
Of course not. Because we don't believe that error handling in C++ is fund= amentally broken. You shouldn't expect other people to agree with such extr= eme positions. Or at least, not in any real quantity.

We know - and ha= ve ample proof - that there are more options for handling errors than just = either return values or exceptions. Yet that's what every discussion about = error handling in C++ turns into: a choice between bad or suboptimal.
=

... `expected` is a return value. You wa= nt to call it something else, but that's what it is.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_1115_460825687.1433665467962-- ------=_Part_1114_307705209.1433665467962-- .