Home arrow static arrow Java Programming [Archive] - Catching causal exceptions from finally{} block?
Warning: Creating default object from empty value in /www/htdocs/w008deb8/wiki/components/com_staticxt/staticxt.php on line 51
Java Programming [Archive] - Catching causal exceptions from finally{} block?
This topic has 84 replies on 6 pages.    « Previous | 1 | 2 | 3 | 4 | 5 | 6 | Next »

Posts:6,750
Registered: 1/25/04
Re: Catching causal exceptions from finally{} block?  
Aug 3, 2004 3:47 PM (reply 45 of 84)



 
of course, i'm not suggesting that :). but this error
has come due to the
requirement to catch checked exceptions.

Right, if the exception had been unchecked, it would have caused a different error.
 

Posts:2,830
Registered: 9/1/03
Re: Catching causal exceptions from finally{} block?  
Aug 3, 2004 3:49 PM (reply 46 of 84)



 
of course, i'm not suggesting that :). but this
error
has come due to the
requirement to catch checked exceptions.

Right, if the exception had been unchecked, it would
have caused a different error.

not caused, shown. it would've shown the real error.

or, the error would not've occured because the implementor would've
been able to write the exception-handling code as they pleased and
would've done it correctly, not just to smother a checked exception.
 

Posts:37,103
Registered: 3/30/99
Re: Catching causal exceptions from finally{} block?  
Aug 3, 2004 5:54 PM (reply 47 of 84)



 
Silk, you seem to be missing the point. Regardless of whether the exception is checked or not, you want the following:
try {    // DB ops}// maybe catch, maybe notfinally {    try {        // close rsltSet    }    catch (whatever) {        // log    }    // repeat for stmt and con} 

Regardless of whether any exceptions in the main try are checked or unchecked, or even if none are thrown, you want the body of finally to execute. Regardless of any exceptions in finally, you want the method to complete however the try block completed. This has nothing to do with whether any exceptions in try or in finally are checked or unchecked.
 

Posts:37,103
Registered: 3/30/99
Re: Catching causal exceptions from finally{} block?  
Aug 3, 2004 5:58 PM (reply 48 of 84)



 
Huh? That doesn't solve the problem, that just hides
it. Checked exceptions or no, you don't want cleanup
to change how your method completes. If all
exceptions
were unchecked, you could successfully insert or
retrieve from the DB, then close could throw an
unchecked exception, and the whole method would then
throw the exception, even though it did its work
successfully.

no comment ? :) (but actually in this case checked
exceptions are hiding
the problem, if they were not checked, then they
originally exception would have
been observed.).

No. If they were unchecked, and you had a finally block (which you should, to close things) then the finally block will still be executed, and if an exception is thrown there and not caught (checked or unchecked) then the method will complete abrubtly with that exception, instead of completing as the try/catch blocks completed as it should.

Now, if the exceptions were unchecked, and you just caught a checked exception, then your catch block wouldn't be executed. Finally stil would though. I'm not sure how you're thinking unchecked exceptions would change anything here.
 

Posts:37,103
Registered: 3/30/99
Re: Catching causal exceptions from finally{} block?  
Aug 3, 2004 6:00 PM (reply 49 of 84)



 
in this case the lack of checked would've meant the
first exception
would be propagated, not smothered.

How so? Can you post code, and what you think will happen, assuming SQLException is unchecked?
 

Posts:37,103
Registered: 3/30/99
Re: Catching causal exceptions from finally{} block?  
Aug 3, 2004 6:02 PM (reply 50 of 84)



 
you should but you don't have to. and with
non-checked
you can
do all this at the location you deem appropriate,
with
checked the
location is forced upon you.

But you said you wouldn't need a finally block.
That's crazy. Whether the exception is checked or
not, it's still thrown at the point it's
encountered.
Whether the exception unchecked has nothing to do
o with whether you need a finally block.

of course, i'm not suggesting that :). but this error
has come due to the
requirement to catch checked exceptions. if the user
was allowed to
put his exception-handling code in as he pleased, it
probably wouldn't
have been so crappy.

So you think if there were no such thing as checked exceptions, the original finally block would have been written correctly? Sounds a bit of a stretch. :-)
 

Posts:2,830
Registered: 9/1/03
Re: Catching causal exceptions from finally{} block?  
Aug 3, 2004 6:07 PM (reply 51 of 84)



 
Silk, you seem to be missing the point. Regardless of
whether the exception is checked or not, you want the
following:

im not, but reading your other replies i think you are a little
confused about what I mean.

im talking from a human perspective, not a code one.

the checked exception causes the errors to be smothered
because the writer was forced to implement exception handling

had they not been forced the error would've been propogated.

or, had they not been forced, they may have chosen to implement
proper error handling, and not ****.

So you think if there were no such thing as checked exceptions,
the original finally block would have been written correctly?
Sounds a bit of a stretch. :-)

not too much of a stretch :) and in the case that they didn't (likely) then
the error (the real error) would've been propogated; hence no problem :)
 

Posts:37,103
Registered: 3/30/99
Re: Catching causal exceptions from finally{} block?  
Aug 3, 2004 6:38 PM (reply 52 of 84)



 
the checked exception causes the errors to be
smothered
because the writer was forced to implement
exception handling

had they not been forced the error would've been
propogated.

or, had they not been forced, they may have chosen to
implement
proper error handling, and not ****.

I really don't know what you're talking about. Can you please post a code snippet and an explanation of wat you think will happen.

Like I said, checked or unchecked, you need the finally block. Why do you think finally would have been done more correctly if all exceptions were unchecked?
 

Posts:6,750
Registered: 1/25/04
Re: Catching causal exceptions from finally{} block?  
Aug 4, 2004 8:23 AM (reply 53 of 84)



 
the checked exception causes the errors to be
smothered
because the writer was forced to implement
exception handling

had they not been forced the error would've been
propogated.

Yes, but at what cost? This is probably what would happen if SQLException were unchecked:
public void myMethod() {// do database stuffresultSet.close();statement.close();}

If the database stuff fails, your result set and statement are left open. Not a disaster, but certainly not a good thing. As I said, if you want to both close resources and report exceptions properly, you must have a try-finally regardless of whether the exception is checked or not.
 

Posts:27,518
Registered: 11/3/97
Re: Catching causal exceptions from finally{} block?  
Aug 4, 2004 8:40 AM (reply 54 of 84)



 
Silk, you seem to be missing the point. Regardless of
whether the exception is checked or not, you want the
following:

im not, but reading your other replies i think you are a little
confused about what I mean.

im talking from a human perspective, not a code
one.

the checked exception causes the errors to be
smothered
because the writer was forced to implement
exception handling

had they not been forced the error would've been
propogated.

or, had they not been forced, they may have chosen to implement
proper error handling, and not ****.

So you think if there were no such thing as checked exceptions,
the original finally block would have been written correctly?
Sounds a bit of a stretch. :-)

not too much of a stretch :) and in the case that they didn't (likely) then
the error (the real error) would've been propogated;
hence no problem :)

You are missing the point that the others are trying to make.

There is no way to write correct SQL handling code without catching exceptions. This is regardless of whether they are checked or not. This would be true of any resource usage code (sockets, files, etc.) So it does not work as an example for your particular point.

You need to provide a different example.
 

Posts:2,830
Registered: 9/1/03
Re: Catching causal exceptions from finally{} block?  
Aug 4, 2004 3:30 PM (reply 55 of 84)



 
Silk, you seem to be missing the point. Regardless
of
whether the exception is checked or not, you want
the
following:

im not, but reading your other replies i think you
are a little
confused about what I mean.

im talking from a human perspective, not a
code
one.

the checked exception causes the errors to be
smothered
because the writer was forced to implement
exception handling

had they not been forced the error would've been
propogated.

or, had they not been forced, they may have chosen
to implement
proper error handling, and not ****.

So you think if there were no such thing as
checked exceptions,
the original finally block would have been written
correctly?
Sounds a bit of a stretch. :-)

not too much of a stretch :) and in the case that
they didn't (likely) then
the error (the real error) would've been propogated;
hence no problem :)

You are missing the point that the others are trying
to make.

not really, all my point was, was just that if the exception had not
been checked, then (assuming no try/catch at all) the first exception
would be observed and the solution (i.e. invalid connection string
or bad query, or whatever) could've been resolved.

if there had been a try/catch hopefully it would've been a well-thought-out
one, not a casual one to compile the code. perhaps it would've been as well
thought out as jverds finally-exception-chaining code, perhaps not. but it would
be more thought out (because there is no reason to implement try/catch
in a runtime exception world unless you plan on doing something).
 

Posts:2,830
Registered: 9/1/03
Re: Catching causal exceptions from finally{} block?  
Aug 4, 2004 3:31 PM (reply 56 of 84)



 
If the database stuff fails, your result set and
statement are left open. Not a disaster, but
certainly not a good thing. As I said, if you want to
both close resources and report exceptions properly,
you must have a try-finally regardless of
whether the exception is checked or not.

well you don't have to. you can, and it might be a good idea,
but it's not a requirement.

and anyway, my whole argument in this thread was not about the
requirement for finally.
 

Posts:37,103
Registered: 3/30/99
Re: Catching causal exceptions from finally{} block?  
Aug 4, 2004 3:51 PM (reply 57 of 84)



 
If the database stuff fails, your result set and
statement are left open. Not a disaster, but
certainly not a good thing. As I said, if you want
to
both close resources and report exceptions properly,
you must have a try-finally regardless of
whether the exception is checked or not.

well you don't have to. you can, and it might
be a good idea,
but it's not a requirement.

If you want to close resources and report exceptions properly, then you have to, as he said.

and anyway, my whole argument in this thread was not
about the
requirement for finally.

Then I've no clue what you were really talking about, except that somehow you were trying to use some code in this thread as a case study as to why checked exceptions are evil.
 

Posts:2,830
Registered: 9/1/03
Re: Catching causal exceptions from finally{} block?  
Aug 4, 2004 3:54 PM (reply 58 of 84)



 
and anyway, my whole argument in this thread was not
about the
requirement for finally.

Then I've no clue what you were really talking about,
except that somehow you were trying to use some code
in this thread as a case study as to why checked
exceptions are evil.

not evil, just not good.

anyway, i've given up trying to convince anyone now, perhaps one
day you may come to the realisation yourself :)
 

Posts:37,103
Registered: 3/30/99
Re: Catching causal exceptions from finally{} block?  
Aug 4, 2004 3:57 PM (reply 59 of 84)



 
not really, all my point was, was just that if the
exception had not
been checked,

Which exception?

then (assuming no try/catch at all) the
first exception
would be observed and the solution (i.e. invalid
connection string
or bad query, or whatever) could've been resolved.

Huh? If there's no try/catch at all then the first exception to occur in the method will be "obvserved" in that the method will throw that exception. This is true regardless of whether that exception is checked or not.

if there had been a try/catch hopefully it
would've been a well-thought-out
one, not a casual one to compile the code.

Yes, and people can put a bunch of bad casts and other misuse of language features in just to get code to compile, so we should eliminate all those features too.

perhaps it
would've been as well
thought out as jverds finally-exception-chaining code,
perhaps not. but it would
be more thought out (because there is no reason to
implement try/catch
in a runtime exception world unless you plan on doing
something).

I totally don't buy into the notion that making all exeptions unchecked would lead to better exception handling. The same people who shortcut exception handling now just to get code to compile would either ignore it altoghether given the opportunity, or would forget to put it in "later" just as they're forgetting to fix their exception handling "later" now, or would handle them incorrectly due to the same general lack of understanding that causes them to handle checked exceptions now.
 
This topic has 84 replies on 6 pages.    « Previous | 1 | 2 | 3 | 4 | 5 | 6 | Next »