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
