Why exceptions for error handling is so important

[deadalnix via Digitalmars-d]

On Wednesday, 14 January 2015 at 07:49:09 UTC, Ola Fosheim 
Grøstad wrote:
>> 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.
>

Once again, no specifics.

>> 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?
>

I was not lost. I know how to recognize a non sequitur when I 
read one.

>> 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's a good thing that you can do all of these in D already.

>> 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.
>

You only need this when you are using static TLS variable, which 
is not that common in practice. The change would makes this 
required all over the place.

>>> 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.
>

It is a known fact that a sufficiently smart compiler will use 
heuristic. It is also fairly obvious that this heuristic will use 
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.

Making a new calling convention is not going to magically make 
things faster. If the calling convention need to do more, it is 
certainly going to make things slower.

Hopefully, function calls are not common at all, so that 
shouldn't be a problem.