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.
