On Mon, Feb 16, 2004 at 03:06:33PM +0000, Will Newton wrote:
> On Monday 16 Feb 2004 1:47 pm, Andrew Suffield wrote:
>
> > However, it results in code that throws exceptions to the user rather
> > than useful error messages, which is amateurish. The user should never
> > see an exception unless there is a bug in your code; errors from the
> > system should be handled properly. This *does* make your code twice as
> > long, but it will not make it any less readable if you do it
> > right. Failing to do it is like failing to test your code before
> > releasing it, or trusting data read from the network - it is not
> > something that has any place in a serious program.
> >
> > "Python makes it easier to write bad code" is a pretty lousy argument.
>
> Exceptions are a valuable programming tool, and I think your criticisms are
> largely unfounded.
My criticisms were of using exceptions to avoid handling errors, which
was the proposed "advantage". If you're going to handle the errors,
then there's no difference between using exceptions or not.
> In C you have:
>
> void shoe()
> {
> /* Do some complicated stuff */
> if (foo == NULL)
> goto cleanup;
> /* Continue complicated stuff */
> if (bar == 3)
> goto cleanup;
>
> cleanup:
> /* Cleanup */
> }
Good grief, that's *terrible* C. Don't do things like that. The
problem here is not a lack of exceptions, it's just bad code. As
usual.
Here's how you should do that:
static bool
check_foo(struct foo *foo)
{
if (sucks(foo->bar))
return false;
if (sucks(foo->baz))
return false;
return true;
}
static bool
process_foo(struct foo *foo)
{
if (!check_foo(foo))
{
/* report and die */
}
/* process it */
}
(Most uses of goto should be replaced with function calls; the rest
should be replaced with block-structure statements)
Highly maintainable (more so than with scattered exceptions, because
everything to do a given task is located in one place), and
considerably more efficient. You can add an error return message from
check_foo() to provide more informative error messages, or split it up
into a sequence of checking functions if some processing is needed in
between.
Exceptions should only be used for exceptional circumstances, and even
then think twice. The single thing for which they are useful is to
throw an error a long way to an unknown handler, which may or may not
understand the error. This is not often useful - library APIs are the
most notable case. Using exceptions in any other circumstances is
usually a really bad idea.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
Attachment:
signature.asc
Description: Digital signature