Why exceptions for error handling is so important

deadalnix via Digitalmars-d digitalmars-d at puremagic.com
Tue Jan 13 17:37:45 PST 2015


On Wednesday, 14 January 2015 at 00:24:41 UTC, Ola Fosheim 
Grøstad wrote:
> I don't see the problem. I'm suggesting value semantics, it can 
> be copied.
>

Then you can't catch by super class. This is not going to fly.

>> When you are in the catch, you are not unwinding anymore. You 
>> could indeed loose chaining to be able to reuse the memory, 
>> that is not what is slow when it come to exception, so it 
>> won't make it fast.
>
> You can't have chaining with this scheme...? But since you can 
> only have one instance it has to be initialized with value 
> semantics. It's a small constraint.
>

You write that paragraph like there is some logical links between 
elements in it, but there is none.

> Not using regular Itanium-style unwinding will make it 
> potentially faster.

The only things that is sure here is that it is going to make the 
non exception path slower. Without specific we can say anything 
else than that.

> Using TLS makes it possible to propagate over non-D code or 
> code where the register pressure is high,

It won't help with register pressure. Having a pointer to an 
exception object in a register is equivalent to having a pointer 
to a TLS memory area in a register.

> it can be optimized away so you don't need TLS if you don't 
> span over non-D code.
>

Without specifics, it is another instance of the sufficiently 
smart compiler running gag.

> Non D functions can cast by setting the TLS memory to an 
> exception value, then do a regular return. The D function that 
> called the non-D function will check TLS memory to see if there 
> is an exception in flight.
>

You don't make things faster by making the calling convention 
easier. There is chance that this is gonna fly any better than a 
flat iron.


More information about the Digitalmars-d mailing list