The Right Approach to Exceptions

[H. S. Teoh]

On Mon, Feb 20, 2012 at 03:57:50PM +1300, James Miller wrote:
> 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.
[...]

The concept doesn't require Lisp macros to work. D already has the
necessary machinery to implement it. All that's needed is some syntactic
sugar to make it very easy to use. Personally I'd like language-level
support for it, but I suspect judicious use of templates may alleviate
even that.


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

D already supports contracts. The current convention throws AssertError
on contract failure, but you could just as easily terminate the program
right there.


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

Error codes are passé. The only reason we still have them is because of
OS's inheriting the legacy APIs and conventions from 20 years ago.


T

-- 
I am Ohm of Borg. Resistance is voltage over current.