First, when I am writing new code it happens commonly that I have to catch some exception and deal with it. But at that early stage of development I don't know WHAT to do with it. I don't know whether I should try to digest it here or throw it up further. Given the way I develop code, I doubt it helps to try to force me to think about the implications of a low-level exception before the larger architecture of the system is settled. Later, when a whole system is written, then I am better able to look at it and see the appropriate places to catch exceptions of various sorts.
I imagine there may be some shops where more experienced developers, "architects" perhaps, can specify a good exception handling strategy before the first code is written. I'd like to know if others have seen this style of development, which I have only imagined.
Second, I don't like the way the try-catch block disrupts the indentation of the main flow of logic. It gives higher precedence (less indentation) to the handling of secondary considerations (the try-catch, the exceptions) while forcing additional indentation of the main steps. If I were a language designer I would experiment with using footnotes to specify exception handling behavior, like this:
THE JAVA WAY
void foo(){
statement 1;
try{
statement 2;
statement 3;
}catch{
panic, clean up;
}
statement 4;
}THE FOOTNOTE WAY
void foo(){
statement 1;
statement 2*;
statement 3*;
statement 4;
{ // footnotes
* panic, clean up;
}
}I think it is easier to read the main flow of logic in the footnote way. But I don't know all the implications; this may be bad for reasons I have not considered.
Cory Foy wrote:
As I got involved in the .NET world, one of the things that bugged me (among lots of other things) was that classes didn't require you to specify or catch exceptions that it created. So even if I wanted to specify that my account class could throw an "AccountOverdrawn" error, I had no way of decorating the class to make it evident, nor had a way for users of my class to be aware or indeed even note that my class could throw it.
...
Note, it is methods which throw exceptions, not classes.
_______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
