
On Fri, Mar 27, 2009 at 10:01 AM, Gregory Petrosyan
Thanks a lot for the answer!
On Thu, Mar 26, 2009 at 4:36 PM, John Lato
wrote: Languages with checked exceptions usually use them for two purposes:
1. Exceptional conditions - disk full, CPU on fire, etc. 2. Error handling - invalid arguments to a function, attempt to invert non-invertible matrix, etc.
Is there any good rule someone can use to decide whether it is error or exception? For me, this is the most important thing, because IMHO you (as library writer) often can't say what is it, it's up to client of your code to decide.
An exception is caused by some sort of interaction with the run-time system (frequently a hardware issue). The programmer typically can't check for these in advance, but can only attempt to recover after they've happened. An error is some sort of bug that should be fixed by the programmer. There is some overlap for certain cases, notably divide by 0. Dividing by 0 is an error, because it's something that the program should never do, and it can be detected and dealt with by the programmer in advance. However most systems allow the divide function to be called with a 0 denominator. The function has a precondition, meaning the onus is on the programmer to not do it, however this is not enforced by the language. If a program does this in error, the result is an exception because the result is not a valid number (this is codified with NaN for IEEE floats). In this case, a programming error results in an exception. The proper solution is to fix the source of the problem, the error, instead of trying to clean up the results.
Henning T., FYI your constant advocacy has gotten at least one person around to this view.
Can you please provide me some links about error/exception separation?
http://haskell.org/haskellwiki/Error http://haskell.org/haskellwiki/Exception