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.