The Right Approach to Exceptions

[James Miller]

I agree that the "Lispian" model works well, though I had issues
trying to get my head around it when I encountered it.

I don't know how you'd make a simpler version for D (D lacking Lisps
ridiculous macros) but maybe something that essentially "returns" a
list of recovery codes (which would unfortunately have to be
documented) that can be called depending on the context of the error.

But error-handling is hard, programmers are naturally lazy, and
checking errors is not something exiting. Exceptions are always going
to be a source of contention amongst people. I know people (mostly C
programmers) that hate them, and other people swear by them. I agree
that incorrect parameters should not be Exceptions, and are
contract-level issues, check your parameters before passing them if
there are conditions on them!

its a difficult topic, hence the ridiculously long thread we have
going here. Error codes are not really the way to go, I prefer more of
an Objective-C/Smalltalk null-pattern style, where null can be a valid
argument almost anywhere the type system allows and code handles it
properly, normally by returning null.

Exceptions are a source of contention due to long-range dependencies,
but you can apply that to many things, and if you treat exceptions as
part of the API, then changing an exception can be considered an API
change and therefore something to be done with care.

James Miller