nothrow by default
nospam at example.com
Thu Jan 9 19:05:24 UTC 2020
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.
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
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://email@example.com and what you
quickly summarized in your idea.
AFAICS nobody (few people?) wants to get rid of the high-level try-catch
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
auto foo = someFunction();
foo = someFunction2(foo);
would be useful in addition.
More information about the Digitalmars-d