"be consistent" | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Cute idea! However, one of the reasons I prefer exceptions to returning any sort of error object is because they act outside the normal return path. The problem with "false == failure" is that it falls down as soon as you have "false" as a legal return value. For example, people often misuse read because it has different meanings for a false return value (0 == EOF, undef == error). People forget to check for the error condition - leading to nasty bugs. The same sort of thing applies to any sort of "funny" return value - which in hindsight was why I was uncomfortable with the code I wrote in Test::Exception extension with (evil?) overloading :-) With exceptions you don't have to worry about any confusion between legal return values and errors. Another advantage of exceptions is that I can separate my error handling code from the error producing code, which makes things like massaging errors between different application tiers so much easier. In reply to Re^2: Best Practices for Exception Handling (no isa)
by adrianh
|
|