Why exceptions for error handling is so important

[via Digitalmars-d]

On Wednesday, 14 January 2015 at 17:53:54 UTC, deadalnix wrote:
> Once again, no specifics.

How is a bitmask (e.g. a set) not specific?

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

Then you should also be able to explain where you got lost.

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

This is about what the compiler does, not what you can do in D. 
So no. You cannot have multiple return paths (like returning to 
the returnaddress+OFFSET) or branch implicitly based on the carry 
flag upon return.

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

That's the point. To have a buffer in TLS so that you don have to 
do transient heap allocations (allocation directly followed by 
deallocation of same object).

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

One needs a calling convention to ensure that the backend puts 
the exception signal in the right register or to do offset 
return. Or to free up more registers. Haskell has a register 
heavy calling convention to speed up Haskell code.

So it is not certainly going to make things slower. Clearing a 
flag/register will most likely fill in a bubble in the pipeline. 
A predicted non-branching branch instruction is fairly cheap.

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

?