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?
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?
Also, it's not usually good practice to allow uncaught exceptions, as in your "pretty error" case, is it?
It's not practical to put a try block around every entry point. MediaWiki has quite a lot of entry points. What's more, the exception framework is only initialised part-way through Setup.php, not at compile time as it would be in C++, so it makes sense to install an exception handler to catch exceptions which are thrown between that point and the return to the enclosing scope (e.g. index.php). 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. Although it might offend purists, the exception handler works perfectly and transparently in all current cases. All the benefits of using exceptions are still present.
-- Tim Starling