Hi all! I've read the topic and I am really surprised so many engeneers arguing for so long and not having systematic approach to the problem.
As I see it, Walter states that there are eenvironmental errors and program bugs, which are non-recoverable. So use exceptions (enforce) for first ones and asserts for the latter. Other folks argue, that you might want to recover from a program bug or not recover from invalid input. Also, exception might be itself a program bug. This is a valid point too. So if both are true, that clearly means that the right solution would be to introduce four categories: a cross product of the obove: - bugs, that are recoverable - bugs, that are unrecoverable - input errors, that are recoverable - input errors, that are not Given that, makes sence to use exceptions for recoverable errors, doesn't matter whether they are bugs or environmental errors, and use asserts, if you can't recover. So, the programmer decides, if his program can recover and puts an assert or an enforce call in his code. The problem is, as always, with libraries. The library writer cannot possibly decide, is some unexpected condition recoverable or not, so he just can't put both assert and enforce into his library function and the caller must check the arguments before calling the function. Yes, this is annoying, but it it the only correct way. But what if he didn't? This brings us to error codes. Yes, they are the best for library error handling, imo, of course, in a form of Maby and Error monads. They are as clear as asking the ccaller to decide, what to do with the error. But I realize, that you, guys, are all against error codes of any kind, so... I would say, that since the caller didn't check the arguments himself the bug becomes unrecoverable by default and there should be an assert, which gives stack trace, so the programmer would insert appropriate enforces before the function call. Finally, this brings me to the conclusion: you don't need a stack trace in the exception, it is never a bug.
