220 18419 <e2eb2c83-8060-442e-ac1e-ac820266787c@isocpp.org> article
Path: news.gmane.org!not-for-mail
From: Nicol Bolas <jmckesson@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Thoughts on Exceptions, Expected, and Error Handling
Date: Fri, 5 Jun 2015 09:01:22 -0700 (PDT)
Lines: 99
Approved: news@gmane.org
Message-ID: <e2eb2c83-8060-442e-ac1e-ac820266787c@isocpp.org>
References: <b171ba85-b2cf-436a-9fa6-11525c186498@isocpp.org> <1d83a5df-f8b1-41fc-a197-319825b5436d@isocpp.org> <97c9b3aa-44b4-4a63-92a0-a571628b0735@isocpp.org> <CALQmNFj87ONznbZZM6uZGF-p70zAJogHA86t+iQctCRWS2b-jw@mail.gmail.com> <303e5cc6-8a3e-4063-880e-eac448ec0dc6@isocpp.org>
 <mkppe8$c1e$1@ger.gmane.org>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1263_130719500.1433520082761"
X-Trace: ger.gmane.org 1433520103 19060 80.91.229.3 (5 Jun 2015 16:01:43 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Fri, 5 Jun 2015 16:01:43 +0000 (UTC)
Cc: mw_triad@users.sourceforge.net
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCEKFTV6ZUMBBU4PY6VQKGQEOFPPGWA@isocpp.org Fri Jun 05 18:01:42 2015
Return-path: <std-proposals+bncBCEKFTV6ZUMBBU4PY6VQKGQEOFPPGWA@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-wg0-f71.google.com ([74.125.82.71])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCEKFTV6ZUMBBU4PY6VQKGQEOFPPGWA@isocpp.org>)
	id 1Z0u3g-0002Ur-U0
	for gclcip-std-proposals@m.gmane.org; Fri, 05 Jun 2015 18:01:24 +0200
Original-Received: by wgme6 with SMTP id e6sf18392107wgm.3
        for <gclcip-std-proposals@m.gmane.org>; Fri, 05 Jun 2015 09:01:24 -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=sARnhuPueorbjHBKeWdgLn6/WrWejxFdHiiWBM4Vz+I=;
        b=ni/01RsHBj/Fw/KI74TTjNuRmMhF0i8lJr3zjRgkVfPHL6ojaBzE/PEFNHKomhG5EC
         jmrr6K4/vxSmfWCXGzHXhdfHLZUIm+gQnE08DVePmbd0oYRqdXs3DqJQxBFESPN4U0t0
         /8bX6rdlcaw42+QXfGTXZX+RXeWUM7ochgHGdf8um1uUWhq6kfCe4K4mG8ICQv74ljNp
         7Gv/nUR68KJr3y3FA/hUnXWUsBk3GXwMTnqkTeVFH4uaogedyA5ogA1h5otmxHOXCuy/
         Xbw4+IvC9TnEZ7Vemi4QXNfnmSFsgyWlDtNXyqz2xXjEyZIFM71paERlqgnd2ED1Lsc/
         jJzA==
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=sARnhuPueorbjHBKeWdgLn6/WrWejxFdHiiWBM4Vz+I=;
        b=jSS0Npbn18wqmpGRCC/kpi3wkLS7b/fD7vPdfItzDYL+XlNMMtJqikOkOZxeasXHil
         lPC49HTSBVZBzeCTc7Y5WOMM3irhqQD2s/IKJq/NkTEtRZbjCxk8/24T3qAiK8aTeGE2
         Jsjpdc0glD5aT8tyvRRQjmoJwNWhGvMD46LtGmtPV24S+aF/nGWkaVu62ICxDaC3MPIs
         HDfJAdO5re02zInLrCBekbQyLEYlMVjaXtS2hsYiMr/H3Iqt2TqFvnvoQQ9qgqHxleSW
         pfrFJtixja05uGXDfnaNhd9/QfI0Y1qzbL0b6a0pwcJyVAuPF33j2nHNGbioEjJaA8wn
         JVdw==
X-Gm-Message-State: ALoCoQnN6drzQ8HQflP01jhjoYD9YTkVeV2dnk9NaPPPW8xiW8DwYZfWB/pZ+NucRvmWY3Ydh7Tw
X-Received: by 10.194.5.229 with SMTP id v5mr3828123wjv.0.1433520084436;
        Fri, 05 Jun 2015 09:01:24 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.140.16.178 with SMTP id 47ls1522580qgb.89.gmail; Fri, 05 Jun
 2015 09:01:23 -0700 (PDT)
X-Received: by 10.140.100.136 with SMTP id s8mr51908qge.2.1433520083192;
        Fri, 05 Jun 2015 09:01:23 -0700 (PDT)
In-Reply-To: <mkppe8$c1e$1@ger.gmane.org>
X-Original-Sender: jmckesson@gmail.com
Precedence: list
Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>,
 <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:18419
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/18419>

------=_Part_1263_130719500.1433520082761
Content-Type: multipart/alternative; 
	boundary="----=_Part_1264_126865619.1433520082761"

------=_Part_1264_126865619.1433520082761
Content-Type: text/plain; charset=UTF-8



On Thursday, June 4, 2015 at 11:05:07 AM UTC-4, Matthew Woehlke wrote:
>
> On 2015-06-04 03:00, Nicol Bolas wrote: 
> > Exceptions are a sledgehammer; expected is a scalpel. Both are good 
> tools 
> > in their domain, yet you seem to be promoting the idea that everyone 
> should 
> > become a surgeon. 
>
> ...I agree with this. I think we need expected, but I don't think we 
> should be promoting it as the One True Method for global error handling. 
> Developers should continue to use their preferred method for error 
> propagation. As much as possible, expected should be friendly to callers 
> that want to turn errors into exceptions.
>

You were doing so well, right up until the last sentence.

The choice needs to be made by the caller, yes. But the choice should be 
made by calling a function that throws exceptions, not by calling some 
member of an `expected`. By then, you've already lost some information that 
the function had about the actual error.

Oh, you can have `.value()` throw if it doesn't hold a value; that's fine. 
But throwing in such a case should not represent the same thing as the 
function actually throwing. It instead represents a caller of the 
`expected` version who didn't do what he was supposed to do.

APIs should provide both, not simply rely on `expected` to throw for users 
who want exceptions.

-- 

--- 
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_1264_126865619.1433520082761
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, June 4, 2015 at 11:05:07 AM UTC-4, Ma=
tthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-06=
-04 03:00, Nicol Bolas wrote:
<br>&gt; Exceptions are a sledgehammer; expected is a scalpel. Both are goo=
d tools=20
<br>&gt; in their domain, yet you seem to be promoting the idea that everyo=
ne should=20
<br>&gt; become a surgeon.
<br>
<br>...I agree with this. I think we need expected, but I don't think we
<br>should be promoting it as the One True Method for global error handling=
..
<br>Developers should continue to use their preferred method for error
<br>propagation. As much as possible, expected should be friendly to caller=
s
<br>that want to turn errors into exceptions.<br></blockquote><div><br>You =
were doing so well, right up until the last sentence.<br></div><br>The choi=
ce needs to be made by the caller, yes. But the choice should be made by ca=
lling a function that throws exceptions, not by calling some member of an `=
expected`. By then, you've already lost some information that the function =
had about the actual error.<br><br>Oh, you can have `.value()` throw if it =
doesn't hold a value; that's fine. But throwing in such a case should not r=
epresent the same thing as the function actually throwing. It instead repre=
sents a caller of the `expected` version who didn't do what he was supposed=
 to do.<br><br>APIs should provide both, not simply rely on `expected` to t=
hrow for users who want exceptions.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1264_126865619.1433520082761--
------=_Part_1263_130719500.1433520082761--

.
