Why exceptions for error handling is so important
via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jan 13 23:49:08 PST 2015
On Wednesday, 14 January 2015 at 01:37:46 UTC, deadalnix wrote:
> 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.
I said value. Use bitmasks. Class hierarchies don't work very
well.
>> 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.
If you cannot follow the logic... Where did you get lost?
> 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.
?
You essentially have two options:
1. A single branch on return.
2. Multiple return paths.
2a) returning to the calling function
2b) using a landing pad (current solution)
> 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.
TLS is in a register already.
>> 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.
This does not take a very smart compiler. You can use heuristics,
such as ones using the function signature.
> 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.
?
Of course you make it faster by allowing the compiler to use it's
own calling conventions.
More information about the Digitalmars-d
mailing list