DConf talk : Exceptions will disappear in the future?

[sighoya]

On Wednesday, 6 January 2021 at 21:27:59 UTC, H. S. Teoh wrote:
> It must be unique because different functions may return 
> different sets of error codes. If these sets overlap, then once 
> the error propagates up the call stack it becomes ambiguous 
> which error it is.
>
> Contrived example:
>
> 	enum FuncAError { fileNotFound = 1, ioError = 2 }
> 	enum FuncBError { outOfMem = 1, networkError = 2 }
>
> 	int funcA() { throw FuncAError.fileNotFound; }
> 	int funcB() { throw FuncBError.outOfMem; }
>
> 	void main() {
> 		try {
> 			funcA();
> 			funcB();
> 		} catch (Error e) {
> 			// cannot distinguish between FuncAError and
> 			// FuncBError
> 		}
> 	}
>

Thanks, reminds on swift error types which are enum cases.
So the type is the pointer to the enum or something which 
describes the enum uniquely and the context is the enum value, or 
does the context describe where to find the enum value in the 
statically allocated object.

> Using the typeid is no good because: (1) typeid in D is a

Sorry, I misspelled it, I meant the internal id in which type is 
turned to by the compiler, not the RTTI structure of a type at 
runtime.

> If you're in @nogc code, you can point to a 
> statically-allocated block that the throwing code updates with 
> relevant information about the error, e.g., a struct that 
> contains further details about the error

But the amount of information for an error can't be statically 
known. So we can't pre-allocate it via a statically allocated 
block, we need some kind of runtime polymorphism here to know all 
the fields considered.

> You don't need to box anything.  The unique type ID already 
> tells you what type the context is, whether it's integer or 
> pointer and what the type of the latter is.

The question is how can a type id as integer value do that, is 
there any mask to retrieve this kind of information from the type 
id field, e.g. the first three bits say something about the 
context data type or did we use some kind of log2n hashing of the 
typeid to retrieve that kind of information.


> When you `throw` something, this is what is returned from the 
> function. To propagate it, you just return it, using the usual 
> function return mechanisms.  It's "zero-cost" because it the 
> cost is exactly the same as normal returns from a function.

Except that bit check after each call is required which is 
neglectable for some function calls, but it's summing up rapidly 
for the whole amount of modularization.
Further, the space for the return value in the caller needs to be 
widened in some cases.

> Only if you want to use traditional dynamically-allocated 
> exceptions. If you only need error codes, no polymorphism is 
> needed.

Checking the bit flag is runtime polymorphism, checking the type 
field against the catches is runtime polymorphism, checking what 
the typeid tells about the context type is runtime polymorphism. 
Checking the type of information behind the context pointer in 
case of non error codes is runtime polymorphism.
The only difference is it is coded somewhat more low level and is 
a bit more compact than a class object.
What if we use structs for exceptions where the first field is 
the type and the second field the string message pointer/or error 
code?


> The traditional implementation of stack unwinding bypasses 
> normal function return mechanisms.  It's basically a glorified 
> longjmp() to the catch block, augmented with the automatic 
> destruction of any objects that might need destruction on the 
> way up the call stack.

It depends. There are two ways I know, either jumping or 
decrementing the stack pointer and read out the information in 
the exception tables.



> Turns out, the latter is not quite so simple in practice.  In 
> order to properly destroy objects on the way up to the catch 
> block, you need to store information about what to destroy 
> somewhere.

I can't imagine why this is different in your case, this is 
generally the problem of exception handling independent of the 
underlying mechanism. Once the pointer of the first landing pad 
is known, the control flow continues as known before until the 
next error is thrown.
> You also need to know where the catch blocks are so that you 
> know where to land. Once you land, you need to know how to 
> match the exception type to what the catch block expects, etc.. 
> To implement this, every function needs to setup standard stack 
> frames so that libunwind knows how to unwind the stack.

Touché, that's better in case of error returns.

> It also requires exception tables, an LSDA (language-specific 
> data area) for each function, personality functions, etc..  A 
> whole bunch of heavy machinery just to get things to work 
> properly.


> Why would you want to insert it into a list?  The context field 
> is a type-erased pointer-sized value. It may not even be a 
> pointer.
>

Good point, I don't know if anyone tries to gather errors in an 
intermediate list which is passed to certain handlers. Sometimes 
exceptions are used as control flow elements though that isn't 
good practice.


> It's not about class vs. non-class (though Error being a struct 
> rather than a class is important for @nogc support). It's about 
> how exception throwing is handled.  The current stack unwinding 
> implementation is too heavyweight for what it does; we want it 
> replaced with something simpler and more pay-as-you-go.

I agree, that fast exceptions are worthwhile for certain areas as 
opt-in, but I don't want them to replace non-fast exceptions 
because of the runtime impact of normal running code.

> That's the whole point of Sutter's proposal: they are all 
> unified with the universal Error struct.  There is only one 
> "backend": normal function return values, augmented as a tagged 
> union to distinguish between normal return and error return.  
> We are throwing out nonlocal jumps in favor of normal function 
> return mechanisms.  We are throwing out libunwind and all the 
> heavy machinery it entails.
>
> This is about *replacing* the entire exception handling 
> mechanism, not adding another alternative (which would make 
> things even more complicated and heavyweight for no good 
> reason).

Oh, no please not. Interestingly we don't use longjmp in default 
exception handling, but that would be a good alternative to Herb 
Sutter’s proposal because exceptions are likewise faster, but 
have likewise an impact on normal running code in case a new 
landing pad have to be registered.
But interestingly, the occurrence of this is much more seldom 
than checking the return value after each function.