nothrow by default

[Johannes Pfau]

Am Thu, 09 Jan 2020 08:02:16 -0800 schrieb H. S. Teoh:

> On Thu, Jan 09, 2020 at 10:07:53AM -0500, Steven Schveighoffer via
> Digitalmars-d wrote:
>> On 1/9/20 7:51 AM, Adam D. Ruppe wrote:
>> > On Thursday, 9 January 2020 at 06:26:41 UTC, Walter Bright wrote:
>> > > I expect that exceptions will soon become a legacy feature.
>> > 
>> > I've seen no evidence of that whatsoever. Exceptions, like GC, are a
>> > proven winner in the real world with the vast majority of actually
>> > existing industry code using them successfully.
> 
> +1.  This anti-exception sentiment I have a hard time understanding.
> 
> 
> [...]
>> I could see "nothrow by default" added making it an easier transition
>> to Swift-like error handling (errors passed back on the stack, made to
>> look like exceptions to user code).
> [...]
> 
> Now *this* I can stand by.  Which makes me wonder if what's bothering
> Walter about exceptions is not so much the concept of exceptions itself,
> but their current implementation via stack unwinding, which requires
> expensive setup of stack frames and what-not.
> 
> But it's possible to implement it differently, while still presenting an
> exception-like interface to user code. You could pass errors back on the
> stack, or even via a register dedicated for indicating error conditions,
> and have the compiler automatically generate code for branching to an
> error-handling part of the function (or have user code explicitly test
> for it, if they so wish). This can be transparent to user code.
> 
> 
> T

I think everyone who wants to move away from exceptions really wants to 
move away from two things:

1) Stack unwinding and the overhead it involves (memory, implementation 
   complexity, ...)
2) (Forced) dynamic allocation of error state. How often do you actually
   use more than 1 word of error state? 

That's basically what Sutter proposes for C++, what I summarized in 
https://forum.dlang.org/post/qusdvn$635$1@digitalmars.com and what you 
quickly summarized in your idea.

AFAICS nobody (few people?) wants to get rid of the high-level try-catch 
exception semantics.

However, some might not want to catch by runtime type but implement the 
catch matching using some kind of error codes. The only thing you loose 
here is having complex exception type trees and catching base classes.

Also as I explained in the linked post, try-catch is fine if you handle 
multiple error sources a once. If you instead have to handle errors for 
each function call individually, a more fine grain solution than

try
{
    auto foo = someFunction();
    try
    {
        foo = someFunction2(foo);
    }
    catch(Exception3 e)
    ...
    catch(Exception4 e)
}
catch(Exception e)
 ...
catch(Exception2 e)

would be useful in addition.

-- 
Johannes