nothrow by default

Sebastiaan Koppe mail at skoppe.eu
Fri Jan 10 09:17:37 UTC 2020


On Friday, 10 January 2020 at 01:40:00 UTC, Walter Bright wrote:
> On 1/9/2020 12:39 PM, H. S. Teoh wrote:
>> It's not really the exceptions themselves
>> that people object to, but the associated implementation 
>> issues.
>
> Yes. They're very costly, even in code that never throws.
>
> An approach I've been using with modest success is to design 
> errors entirely out of the code. For example, in dmd a lot of 
> errors are handled by making a special AST node for "Error". 
> Subsequent code does nothing with Error nodes.
>
> (Analogously to how floating point code deals with errors, it 
> just sets a NaN value, which is sticky.)
>
> Another technique is to check for errors in the data first, 
> then the processing code does not have to check, and cannot 
> fail.
>
> I enjoy trying to set up an API so it cannot fail, then no 
> special code is needed for errors. Of course, this isn't always 
> possible, and isn't a general solution. But it's nice when one 
> can make it work.
>
> P.S. I hate throwing constructors, and would force them to be 
> nothrow in D if I weren't faced with a tsunami of objection to 
> it :-)

Well said. Another option would be functional programming, with 
an explicit either type. But it is not for everyone.

I have found that I don't need exceptions a lot, and when I do, 
it is almost always because I want to take advantage of the fact 
that they add implicit returns up call stack until the nearest 
catch. Then they come in real handy, especially because they are 
transparent to the intermediate functions.

Of course, that is exactly why they are costly.

They works great with IO, but I tend to avoid them for everything 
else.


More information about the Digitalmars-d mailing list