220 33087 <12a8cbd7-49cc-4a4f-810d-39670fa1472a@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Support for exception-less error handling Date: Mon, 3 Jul 2017 13:50:07 -0700 (PDT) Lines: 148 Approved: news@gmane.org Message-ID: <12a8cbd7-49cc-4a4f-810d-39670fa1472a@isocpp.org> References: <6856d8da-734e-44c9-b45b-890f3142f83b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2096_232308588.1499115007248" X-Trace: blaine.gmane.org 1499115015 7563 195.159.176.226 (3 Jul 2017 20:50:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 3 Jul 2017 20:50:15 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB7635LFAKGQE7VJDGAQ@isocpp.org Mon Jul 03 22:50:11 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f198.google.com ([209.85.223.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dS8IF-0001N1-ML for gclcip-std-proposals@m.gmane.org; Mon, 03 Jul 2017 22:50:03 +0200 Original-Received: by mail-io0-f198.google.com with SMTP id k2sf100992113ioe.4 for ; Mon, 03 Jul 2017 13:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=MIePyBBfUDt7N6qiaf5DYxTRHBnqTE//rUlVPjV5XPk=; b=Ua4HKwkcXf8UfjRMbi9Oom+kB9I2rFWcAg82SHzWfPEXjfbMJ+qhIOqtSePS7r7LfQ BGBhVPejPu1dTwhmx5DkPZWOzv+j66qYC/jcGkOTyIA9J1gUCFl7Rtdbpw2Odryf4TX2 N8FSQnJCNBZPhSLs9TXpowbtXNHzHO+t1C6YaVvzCqt3XyTGdR1mdg/RH+qAr1tJaAeH zv60fv7vU2Gjfb1BPpCovVGETcR88u0fw37VBHpfB8NPZvQd0wBcRYqHN0u4LzrBeOEk FjUo+fKkY5RGHvN7Wsl5xZLo0rsQTeYjJ1J0vCwxZ24DO9ZcXT++5Pb+fZDcneratbyy lWWQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=MIePyBBfUDt7N6qiaf5DYxTRHBnqTE//rUlVPjV5XPk=; b=UO4ZMiowiQeLwUHHgJ+sJZ0L7SBm0Lcd9bZtT7u4aokp3NnD+x3kOJGPTv4S10BHzt kniMUztfml6mKlpICC86dOKzoywPMjhq4r8uQ3U4m+EiCIH7S4/SB500j2ilXq1o5pmj 3dqMYZxED6I/V9qooynmD0gxK9XY8Xy3QXChFJ9hu4vNHiSem6qyXvzQKOGtKTOxw6d1 uQCWwAx8J1Mrt80Rj46GJh+jDnFuKSf6OdXaimMxKE88sEkFESv/rpClb7r4gS2eSDET LcewJCauCSW0q3kG/v7CeqewEWcbdbvQoFDj2kNFK8FUBGa4Ls5XE+Z5ppGHjEVQWgxS fvSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=MIePyBBfUDt7N6qiaf5DYxTRHBnqTE//rUlVPjV5XPk=; b=qSgxE3e4/Tu8UlcRzrdObrlb1HNmG9UimzdSdNJfj0QoftDZGPu89ti2MMOlNNb9Or UdYUKavv2GzTPgJfeEYBYyhXnkVJRDh8+JgHC1zpb7Xs0L3FBCD1U9NdAUEzE8TMeo2J 2gIzP08+D3F/qhz1dDGrg70i/DxKLlKFPLbP8zqMqFIxiEcYBM+DBumMc7EQ4sWKv434 v+dkgeoqrmCApfNALZjgs5BWHSVKSrqbWbFXVbaP5zUutVaK46YpvNic1qS7IUHTQ2OP 8VL28AsbA3d3XEjt2tQHXaMskhmh2dktGwnOOI6FY2dxZmF6h+oSoe+tuRT3/xGDoym+ 18hA== X-Gm-Message-State: AKS2vOyfJ9AmiPnr1myWJfXqTRu6p/2jERtW+uDgvfO0RHaGBQCjFWGE DXllG2yvfW98F5zx X-Received: by 10.36.160.194 with SMTP id o185mr19192243ite.7.1499115008959; Mon, 03 Jul 2017 13:50:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.93.4 with SMTP id w4ls7035182ita.22.gmail; Mon, 03 Jul 2017 13:50:07 -0700 (PDT) X-Received: by 10.36.65.25 with SMTP id x25mr150898ita.9.1499115007662; Mon, 03 Jul 2017 13:50:07 -0700 (PDT) In-Reply-To: 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:33087 Archived-At: ------=_Part_2096_232308588.1499115007248 Content-Type: multipart/alternative; boundary="----=_Part_2097_1814101434.1499115007249" ------=_Part_2097_1814101434.1499115007249 Content-Type: text/plain; charset="UTF-8" On Monday, July 3, 2017 at 4:44:38 PM UTC-4, Brittany Friedman wrote: > > On Mon, Jul 3, 2017 at 3:21 PM, Bengt Gustafsson > wrote: > >> I would doubt that the runtime overhead of exceptions is worse than that >> of checking return values and continue returning out the call stack. >> Especially in the no-error case it should be more efficient as those ifs >> have potentially large runtime penalty regardless of if the jump >> instruction is taken or not, while the exception unwinding code is >> typically very asymmetric with a minimized runtime cost for the non-throw >> case. >> >> So before suggesting another mechanism that simplifies writing code based >> on error returns I would suggest actually measuring the performance in the >> throwing and non-throwing case compared to a return value/if-based >> solution. This article is not totally clear but casts serious doubts about >> any speed gain from avoiding exceptions: >> >> >> https://stackoverflow.com/questions/13835817/are-exceptions-in-c-really-slow >> >> Unfortunately (or fortunately as it is so old) the TS report linked to >> does not show numbers for exception handling. Maybe someone else can point >> to a paper detailing the performance for the different approaches? >> >> > There are plenty of reasons to use error codes or error-code-like-entities > that are not motivated solely by performance considerations. > > Some users find error codes easier to audit and work with (no hidden > control flow). > Some users are on platforms that recommend against or forbid the use of > exception handling. The platform vendor in question does not provide a > high-quality exception handling mechanism. > Some users don't want to pay for the *memory* overhead of the so-called > """""""""zero cost""""""""" (there are not enough scare-quotes in the > world) mechanism. > Exceptions do not compose well (see the now defunct exception_list) > Neither do error codes. Generally speaking, two sets of error codes from two different libraries cannot be composed without creating a list of error codes. If we presume that exceptions can in *some* cases be slower, then if > "errors" are very common or if you require *predictable* performance > characteristics, exceptions may be unacceptable. > That's a "performance consideration". -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/12a8cbd7-49cc-4a4f-810d-39670fa1472a%40isocpp.org. ------=_Part_2097_1814101434.1499115007249 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, July 3, 2017 at 4:44:38 PM UTC-4, Brittany Frie= dman wrote:
On Mon, Jul 3, 2017 at 3:21 PM, Bengt Gustafs= son <bengt.gu...@beamways.com> wrote:<= br>
I wou= ld doubt that the runtime overhead of exceptions is worse than that of chec= king return values and continue returning out the call stack. Especially in= the no-error case it should be more efficient as those ifs have potentiall= y large runtime penalty regardless of if the jump instruction is taken or n= ot, while the exception unwinding code is typically very asymmetric with a = minimized runtime cost for the non-throw case.

So before= suggesting another mechanism that simplifies writing code based on error r= eturns I would suggest actually measuring the performance in the throwing a= nd non-throwing case compared to a return value/if-based solution. This art= icle is not totally clear but casts serious doubts about any speed gain fro= m avoiding exceptions:


Unfortunately (or fortunately as it is so old) the TS repor= t linked to does not show numbers for exception handling. Maybe someone els= e can point to a paper detailing the performance for the different approach= es?


<= /div>
There are plenty of reasons to use error codes or error-code-like= -entities that are not motivated solely by performance considerations.

Some users find error codes easier to audit and work w= ith (no hidden control flow).
Some users are on platforms that re= commend against or forbid the use of exception handling. The platform vendo= r in question does not provide a high-quality exception handling mechanism.=
Some users don't want to pay for the *memory* overhead of th= e so-called """""""""zero cost= """""""""=C2=A0(there are not = enough scare-quotes in the world) mechanism.
Exceptions do not compose well (see the now d= efunct exception_list)

Neither= do error codes. Generally speaking, two sets of error codes from two diffe= rent libraries cannot be composed without creating a list of error codes.
<= div>
If we presume that exceptions can in *s= ome* cases be slower, then if "errors" are very common or if you = require *predictable* performance characteristics, exceptions may be unacce= ptable.

That's a "per= formance consideration".

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/12a8cbd7-49cc-4a4f-810d-39670fa1472a= %40isocpp.org.
------=_Part_2097_1814101434.1499115007249-- ------=_Part_2096_232308588.1499115007248-- .