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