DConf talk : Exceptions will disappear in the future?

sighoya sighoya at gmail.com
Tue Jan 5 18:23:25 UTC 2021


Personally, I don't appreciate error handling models much which 
pollute the return type of each function simply because of the 
conclusion that every function you define have to handle errors 
as errors can happen everywhere even in pure functions.

You don't believe me? What about memory overflow errors which can 
occur in any stack/heap allocation? Don't know how this is 
handled in D but in Java you got exceptions for this as well.

The other point is the direction which is chosen in Go and Rust 
to make error handling as deterministic as possible by 
enumerating all possible error types.
Afaict, this isn't a good idea as this increases the fragile code 
problem by over specifying behavior. Any change requires a 
cascade of updates if this is possible at all.
What you do in Rust then?, simply panic?
Though, it doesn't mean that it is bad in every case.

By churning different language design forums it all comes down to 
the point, every time, that the default error handling model 
equipped with the considered language is dump and that people 
call for extensions from other languages, even ones which include 
exception handling to improve things.

I see this in Rust and Go and even in Swift forums that people 
are annoyed how it currently works.

No error handling model was the HIT and will never be, therefore 
I would recommend to leave things as they are and to develop 
alternatives and not to replace existing ones.


More information about the Digitalmars-d-learn mailing list