Yeah I've come around to the C# way of thinking almost. Though I play with
the idea that one should be able to register for exceptions as essentially
events, but the continuation characteristics could get ugly (ala QuickBasic
or Visual Basic "on error" type stuff).
Though at the end of the day, I just think developers should decide to make
more judicious use of checked exceptions and not make a checked exception
out of everything. For instance if all you ever do is catch that exception
and throw a runtime exception, then it probably should have been one in the
first place. I'd guess 90% of the checked exceptions I see in applications
*shouldn't* be checked exceptions.
-Andy
> From: "Richard O. Hammer" <[EMAIL PROTECTED]>
> Reply-To: "Research Triangle Java User's Group mailing
> list."<[EMAIL PROTECTED]>
> Date: Tue, 06 Jul 2004 15:34:47 -0400
> To: "Research Triangle Java User's Group mailing list."<[EMAIL PROTECTED]>
> 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
