I think exceptions are very bad idea. Not nearly as bad as implicit nullability but comparable. Hacky emulations of exceptions... Well I don't want to be near such code.
But that was interesting read non the less, thanks OP.
I agree it was an interesting read. Haven't thought about setjmp and longjmp in many years.
>> I think exceptions are very bad idea.
There are many cases, API implementations for example, where I cannot think of a better solution. Packing result codes into returned data, using return values, using global state, using passed state buffers, all those approaches are worse, imo, and lead to less readable and maintainable code. What's your preferred alternative?
In Haskell I use Maybe's, Either's and their ilk (packing result code in returned data I guess?), in C - your usual boolean return values like this:
bool parse_literal (ParsingState* state, LiteralValue* pResult).
In Java/C# I have to use what other people are using :)
My dislike of exceptions (as well as errno and Set/GetLastError) is due their masking, hiding error conditions and situations. And I prefer everything to be stated clearly. Including error handling code (answer to 'did I handled all possible failures of calling this?' should be instant).
Unfortunately proper error handling is hard, nearly as much as 'naming things' :)
>> I think exceptions are very bad idea.
There are many cases, API implementations for example, where I cannot think of a better solution. Packing result codes into returned data, using return values, using global state, using passed state buffers, all those approaches are worse, imo, and lead to less readable and maintainable code. What's your preferred alternative?