Richard, it's hack and unreasonable, but I usually fill such code blocks with "// REVISIT" early on -- a reminder that I have unfinished work to do.
Then, as part of the build process, have a lint-like process that issues warnings for occurrences of that phrase. Later on in the process, you can make such occurrences build errors to force people to deal with them (hopefully intelligently). Then again, I still use vi. David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard O. Hammer Sent: Tuesday, July 06, 2004 3:35 PM To: Research Triangle Java User's Group mailing list. Subject: Re: [Juglist] Structured Exception Handling I can't answer Cory's question directly, but I'll write some because I've never felt at ease with the exception framework in Java. It has always seemed a little unnatural to me, for two reasons. 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 _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
