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