About use of specific error
tim Rowledge
tim at rowledge.org
Sat Mar 4 05:42:43 UTC 2006
On 3-Mar-06, at 6:48 PM, David T. Lewis wrote:
>
> I have a hunch that there is a human factors aspect of this also.
> In practice, programming with exceptions seems to attract some of
> the worst elements of human (and organizational) behavior.
Can't argue with that; you only have to look at code to quickly gain
that feeling. They're complicated. They're cool. They're so obviously
clever stuff. You just have to use them all over the place to look
like you really, really, know hard programming. It's part of being a
hotshot c001d00d codemonkey.
Exceptions are really nothing more than a way of throwing your hands
up and screaming
"somebody up there help me!" or a way to send a warning or progress
signal up the callstack. I've noticed on a number of occasions that
people tend to forget that 'up the callstack' part. The tricky bit,
the stuff that causes much of the confusion is the strange and
complex things you can do when handling an exception. Add in nesting
and pass throughs and returnWith and it's no wonder it gets to be too
much.
I claim there's a serious lack of tools to help with making use of
exceptions which merely adds to the feeling of a big disconnect
between the code raising the exception and a possible handler. Add in
the inheritance that makes it possible for some code to signal
FooBarException and for it to be handled in code that refers to
WibbleException and you can lose anyone, even me. Oh and then there's
bugs to toss in as well; non-proceedable exceptions that can proceed
and so on.
I'm sure that it is possible to make a system for using exceptions
that is clear, intelligable and well engineered. We just don't have
one yet.
tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- If you called him a wit, you'd be half right.
More information about the Squeak-dev
mailing list
|