On Wed, 07 Jun 2006 16:54:02 +1000, Tim Starling wrote:
Steve Bennett wrote:
On 6/7/06, Tim Starling t.starling@physics.unimelb.edu.au wrote:
which is better? Should the backend dictate the error format by specifying an exception class with a fixed format? Of course, a caller wishing to override the formatting could catch the exception, but is that better than the old method of using a success/failure return value?
If catching the exception to override the formatting would require the additional 10 lines of boilerplate code that you mention below then that seems to be a good argument against using an exception class.
Should error handling be completely exception-dominated? Is there any role for success/failure return values in a language with exception support?
Assuming this is a general question not specifically related to MediaWiki, the general answer is that exceptions should only be used for exceptional circumstances, and likely failures are better off handled with return codes. It's better to use exceptions for weird things like running out of memory, suddenly being unable to access the disk, or an assertion failing, rather than something as banal as a bad filename being supplied, for instance.
Do you have some sort of justification for this view?
I share and have considered that view; here are two justifications:
* consistency. A caller of a routine that needs to access the routine's status shouldn't have to ask itself, "now, do I need to handle an exception, check the return code, or both?"
* clarity. Due to their automatic propagation, exceptions are capable of interrupting the normal flow of code in an unusual way that can make it harder to read, and so should be used sparingly.
A useful policy could be to treat exceptions and their handling as one part of a debugging and quality-control framework (e.g. throwing exceptions on assertion failures as the quoted advice suggests), and to use them only conservatively for other error types. One set of criteria for non-debugging and non-QC use might be that the exceptional circumstance is: * critical but rare and unexpected, and * beyond the direct control of the software, and * a possibility nearly everywhere in the code.
A previous question was:
Should the backend dictate the error format by specifying an exception class with a fixed format?
If consistency of error formatting is to be implemented - and it seems like a good idea to me - then it could be achieved by means other than an exception class. One possibility is an ErrorFormatter class. Another is an advertised and simple protocol for error output based on use of css classes for styling.
[...]
PHP has a bug with exceptions thrown from within catch blocks, and this means that standard exception handling requires some 10 lines of boilerplate, making a try block on every entry point less practical still.
[...]