On Wed, 07 Jun 2006 16:54:02 +1000, Tim Starling wrote:
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?
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.
[...]
--
http://members.dodo.com.au/~netocrat