Steve Bennett wrote:
On 6/7/06, Tim Starling
<t.starling(a)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