220 18416 article Path: news.gmane.org!not-for-mail From: Nicola Gigante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Thoughts on Exceptions, Expected, and Error Handling Date: Fri, 5 Jun 2015 14:34:18 +0200 Lines: 217 Approved: news@gmane.org Message-ID: References: <1d83a5df-f8b1-41fc-a197-319825b5436d@isocpp.org> <97c9b3aa-44b4-4a63-92a0-a571628b0735@isocpp.org> <1c62b01e-9160-42a2-9ad8-88587a2347e7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_26FAAA0D-E798-4D9D-9309-650BB750A7A6" X-Trace: ger.gmane.org 1433507703 27887 80.91.229.3 (5 Jun 2015 12:35:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jun 2015 12:35:03 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDMMZOF5V4KBBT5OY2VQKGQE4DN7P7Y@isocpp.org Fri Jun 05 14:34:46 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f70.google.com ([74.125.82.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z0qpS-0001np-21 for gclcip-std-proposals@m.gmane.org; Fri, 05 Jun 2015 14:34:30 +0200 Original-Received: by wgla2 with SMTP id a2sf17088005wgl.1 for ; Fri, 05 Jun 2015 05:34:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=PocbSlCXe4Jgf2vBHiTO+++4TGa41RNOKSBMg3gR9ak=; b=H0rBLH5ZE0mOFDZVQwxGnLPj52U043Lqj9Sx2SMrZ3Er2CUI7qYqU1qQJlp6kU+m9E tOl7IC5rq7LAjNznzL0mzI9z9pD9NtRsG6MpTjGOsqxpepECCViSKDooQ3laIFWZtjnd L35nCGAgOtawSX9tN/C/kD+NYGxygpVYYdfOEw72h8wNXB7kgMioLmQs3q2YipjV44cG oIU3icjXIZwC6DKxCwR3mn06QboYJ5A7NACJLLX4dbTqfaFEux/3lUh9KJEBdZW3ak1n otDY60qtQTPUk+hP87ecp46stjCQlBOTGUMd/j+c3ll4iaKinZU9RopTxFulzHNdrVpF f+EQ== X-Gm-Message-State: ALoCoQnlp70+X9mtmOoJ4vTB5HTO7WK4J+FByiPz4hIZ7yJREpWwK3k+aoxWhqJR7YopStu3+s6C X-Received: by 10.112.148.101 with SMTP id tr5mr3068660lbb.13.1433507664385; Fri, 05 Jun 2015 05:34:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.186.161 with SMTP id fl1ls401715wic.0.gmail; Fri, 05 Jun 2015 05:34:23 -0700 (PDT) X-Received: by 10.180.103.227 with SMTP id fz3mr9820080wib.45.1433507663164; Fri, 05 Jun 2015 05:34:23 -0700 (PDT) Original-Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com. [2a00:1450:400c:c05::232]) by mx.google.com with ESMTPS id gj6si3899367wib.101.2015.06.05.05.34.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2015 05:34:23 -0700 (PDT) Received-SPF: pass (google.com: domain of nicola.gigante@gmail.com designates 2a00:1450:400c:c05::232 as permitted sender) client-ip=2a00:1450:400c:c05::232; Original-Received: by wibut5 with SMTP id ut5so19714448wib.1 for ; Fri, 05 Jun 2015 05:34:22 -0700 (PDT) X-Received: by 10.194.71.226 with SMTP id y2mr6083028wju.34.1433507662599; Fri, 05 Jun 2015 05:34:22 -0700 (PDT) Original-Received: from gigamac.fritz.box (adsl-ull-235-207.49-151.net24.it. [151.49.207.235]) by mx.google.com with ESMTPSA id bg4sm10386452wjc.10.2015.06.05.05.34.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jun 2015 05:34:21 -0700 (PDT) In-Reply-To: <1c62b01e-9160-42a2-9ad8-88587a2347e7@isocpp.org> X-Mailer: Apple Mail (2.2098) X-Original-Sender: nicola.gigante@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of nicola.gigante@gmail.com designates 2a00:1450:400c:c05::232 as permitted sender) smtp.mail=nicola.gigante@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:18416 Archived-At: --Apple-Mail=_26FAAA0D-E798-4D9D-9309-650BB750A7A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > Il giorno 05/giu/2015, alle ore 11:35, R=C3=B3bert D=C3=A1vid ha scritto: >=20 >=20 > 2015. j=C3=BAnius 4., cs=C3=BCt=C3=B6rt=C3=B6k 0:41:24 UTC+2 id=C5=91pont= ban Nicol Bolas a k=C3=B6vetkez=C5=91t =C3=ADrta: > Yeah, Java tried that with `throw` specifications. It is fairly widely ag= reed that this approach sucked. >=20 > Why? I mean, Google/Bing/insert_your_favorite_search_engine_here gives re= sults, but very few of them go beyond "it sucks", and those that do, they a= re inconsistent, and mostly rant on the *implementation*, not the *idea*. >=20 > In C++03 standardese it sucked because of a design issue that resulted in= a big performance hit: all functions having to catch(...) and call std::te= rminate if encountered a non-listed exception. It was "less" problem for so= me compilers because they chose to ignore it (making them essentially non-s= tandard) apart from the empty specification, making essentially throw() =3D= =3D noexcept v0.9. >=20 The main problem of Java exception specifications is not exception specific= ations themselves, imho. The problem is that exceptions are the default and only error mechanism use= d in the Java world (besides returning null objects), and the syntax is not convenient enough f= or this heavy usage. In my opinion it is good to use the type system to _force_ the caller to ha= ndle the error (even if just to explicitly ignore it). That=E2=80=99s the best practice in the strongly typed functional programmi= ng world, and that=E2=80=99s what expected would achieve (in contrast to C++03 exception specifications which= were handled _at runtime_). The problem with Java checked exceptions is that the syntax simply is not u= p to the task. Every time you call a function, and you don=E2=80=99t want to propagate the= error to your caller, you have to add a try {}catch{} block. This disrupt the control flow: what = if you need to do something different depending on the success of the call? instead of a simp= le branch you have to do one thing immediately after the call and another thing in a _whole ot= her code block_. What if the recovery code is the same among a few calls? you can catch mult= iple exceptions of the same type in the same catch{} block, but then you cannot discriminat= e who raised the exception. At the end, the mechanism is only a burden to the programmer, makes the cal= ling code less readable, and folks just make their exceptions unchecked exceptions (those that you d= on=E2=80=99t have to add to the exceptions list) or end up wrapping all the function code with an empty cat= ch{} block. Useless=E2=80=A6 If the language had an optional/expected-style way to signal the _absence o= f a return value_, and the libraries consistently used that instead of exceptions for that task, relyi= ng on exceptions to only signal _exceptional_ situations (like IO failures), the whole checked = exception mechanism would be great and useful. Note that expected-style error handling also needs good syntax to be effect= ively used and not incur in the same problems: that=E2=80=99s why I advocate it for C++ only n= ow that we=E2=80=99ll have the monadic 'do notation' provided by the await 2.0 proposal. > Robert Bye, Nicola --=20 ---=20 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 e= mail 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-proposa= ls/. --Apple-Mail=_26FAAA0D-E798-4D9D-9309-650BB750A7A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
Il giorno 05/giu/201= 5, alle ore 11:35, R=C3=B3bert D=C3=A1vid <lrdxgm@gmail.com> ha scritto:


2015. j=C3=BAnius 4., cs=C3=BCt=C3=B6rt=C3=B6k 0:41:24 UTC+2 id=C5= =91pontban Nicol Bolas a k=C3=B6vetkez=C5=91t =C3=ADrta:
Yea= h, Java tried that with `throw` specifications. It is fairly widely agreed = that this approach sucked.

Why? I mean, Google/Bing/insert_your_favorite_sear= ch_engine_here gives results, but very few of them go beyond "it sucks", an= d those that do, they are inconsistent, and mostly rant on the *implementat= ion*, not the *idea*.

In C++03 standardese it = sucked because of a design issue that resulted in a big performance hit: al= l functions having to catch(...) and call std::terminate if encountered a n= on-listed exception. It was "less" problem for some compilers because they = chose to ignore it (making them essentially non-standard) apart from the em= pty specification, making essentially throw() =3D=3D noexcept v0.9.


The main problem of Java exception specifications is not exception= specifications themselves, imho.
The problem is that exceptions = are the default and only error mechanism used in the Java world
(= besides returning null objects), and the syntax is not convenient enough fo= r this heavy usage.

In my opinion it is= good to use the type system to _force_ the caller to handle the error
(even if just to explicitly ignore it).
That=E2=80=99s the = best practice in the strongly typed functional programming world, and that= =E2=80=99s what
expected would achieve (in contrast to C++03 exce= ption specifications which were handled _at runtime_).

The problem with Java checked exceptions is that the synta= x simply is not up to the task.
Every time you call a function, a= nd you don=E2=80=99t want to propagate the error to your caller,
= you have to add a try {}catch{} block. This disrupt the control flow: what = if you need to do
something different depending on the success of= the call? instead of a simple branch you have
to do one thing im= mediately after the call and another thing in a _whole other code block_.
What if the recovery code is the same among a few calls? you can c= atch multiple exceptions
of the same type in the same catch{} blo= ck, but then you cannot discriminate who raised the exception.
At the end, the mechanism is only a burden to the p= rogrammer, makes the calling code less readable,
and folks just m= ake their exceptions unchecked exceptions (those that you don=E2=80=99t hav= e to add to the
exceptions list) or end up wrapping all the funct= ion code with an empty catch{} block. Useless=E2=80=A6

If the language had an optional/expected-style way to sign= al the _absence of a return value_, and the
libraries consistentl= y used that instead of exceptions for that task, relying on exceptions to
only signal _exceptional_ situations (like IO failures), the whole= checked exception mechanism would
be great and useful.

Note that expected-style error handling also nee= ds good syntax to be effectively used and not
incur in the same p= roblems: that=E2=80=99s why I advocate it for C++ only now that we=E2=80=99= ll have the monadic
'do notation' provided by the await 2.0 propo= sal.

Robert

= Bye,
Nicola

--

---
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>.
--Apple-Mail=_26FAAA0D-E798-4D9D-9309-650BB750A7A6-- .