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:2,830
Registered: 9/1/03
Re: Catching causal exceptions from finally{} block?  
Aug 4, 2004 4:06 PM (reply 60 of 84)



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

Which exception?

any exception, the SQLException in this case. "the" exception that was
causing the try/catch to be written.

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.

no it isn't. if the exception is checked, and the method does not
"throws Exception", then a try/catch is required.

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

perhaps you could go short on it ? (very lame joke).

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,

but the process that leads to them being able to 'forget' about it
now means the exception is smothered, generally. if they 'forgot'
about it with runtimeExceptions the errors would be seen as they
occur, hence allowing them to be fixed.
 

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



 
I totally don't buy into the notion

perhaps you could go short on it ? (very lame joke).

I liked it. :-)

but the process that leads to them being able to
'forget' about it
now means the exception is smothered, generally. if
they 'forgot'
about it with runtimeExceptions the errors would be
seen as they
occur, hence allowing them to be fixed.

This is true, but isn't it worse to encourage developers not to close resources? This is an aspect of checked exceptions I hadn't even thought of in the other thread. Now that I think about it I'm not sure if that's a side-effect or a central advantage of them, and I'm too hungry to think it through. Tomorrow, then.
 

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



 
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.

no it isn't. if the exception is checked, and the
method does not
"throws Exception", then a try/catch is required.

Then the exception is observed by being caught or by being declare to be thrown from the method. If somebody writes a crappy handler here, they can just as easily write a crappy handler for the unchecked exception further up the chain, or forget to handle it altogether and have the thing crash in production after running flawlessly for a month.

I really don't see what point you're trying to make.

perhaps you could go short on it ? (very lame joke).

I don't like going short. I'd just buy a put instead.

but the process that leads to them being able to
'forget' about it
now means the exception is smothered, generally. if
they 'forgot'
about it with runtimeExceptions the errors would be
seen as they
occur, hence allowing them to be fixed.

But you never know when that will happen, so you're not necessarily any better off. You're advocating removing a useful language feature because it might lead to detection of errors that are otherwise hidden due to programmer's errors in using that feature.

Also, keep in mind, if you smother a checked exception, chances are it will manifest itself as an unchecked one at some point anyway, or at the very least, improper behavior. Either way, an exception occurred, you didn't handle it properly, and your program malfunctioned.
 

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



 
This is true, but isn't it worse to encourage
developers not to close resources? This is an aspect
of checked exceptions I hadn't even thought of in the
other thread. Now that I think about it I'm not sure
if that's a side-effect or a central advantage of
them, and I'm too hungry to think it through.
Tomorrow, then.

I don't think checked vs. unchecked really does any more to encourage closing resources. If you're the sort who just does catch Exception {} to get your code to compile, you're probably not going to have a proper finally block anyway.
 

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



 
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.

no it isn't. if the exception is checked, and the
method does not
"throws Exception", then a try/catch is required.

Then the exception is observed by being caught or by
being declare to be thrown from the method. If
somebody writes a crappy handler here, they can just
as easily write a crappy handler for the unchecked
exception further up the chain,

why would anyone ever write a crappy handler for an unchecked
exception ?

there is no point.

you can just not have the handler at all, hence the exception is
visible in whatever system handles it (jvm, container, whatever).

but the process that leads to them being able to
'forget' about it
now means the exception is smothered, generally. if
they 'forgot'
about it with runtimeExceptions the errors would be
seen as they
occur, hence allowing them to be fixed.

But you never know when that will happen, so you're
not necessarily any better off. You're advocating
removing a useful language feature because it might
lead to detection of errors that are otherwise hidden
due to programmer's errors in using that feature.

yep.

Also, keep in mind, if you smother a checked
exception, chances are it will manifest itself as an
unchecked one at some point anyway, or at the very
least, improper behavior.

improper and confusing behaviour that would take longer to
debug then a stack trace pointing you at the exact line where
things went wrong. I know which I would prefer.
 

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



 
I totally don't buy into the notion

perhaps you could go short on it ? (very lame joke).

I liked it. :-)

but the process that leads to them being able to
'forget' about it
now means the exception is smothered, generally. if
they 'forgot'
about it with runtimeExceptions the errors would be
seen as they
occur, hence allowing them to be fixed.

This is true, but isn't it worse to encourage
developers not to close resources? This is an aspect
of checked exceptions I hadn't even thought of in the
other thread. Now that I think about it I'm not sure
if that's a side-effect or a central advantage of
them, and I'm too hungry to think it through.
Tomorrow, then.

I don't think it does ... it encourages them to implement their own
error handling. they can still close the resource, they are just not
required to actually see if it worked.

they have the option of seeing if it worked, via the RuntimeException,
so if they are a good programmer they may choose to do this. but
at least if they don't do it the exception doesn't get smothered if they
have decided to ignore the exception.

i.e there are some scenarios:
1. Good programmer: handles the exception appropriately. CE, or RTE are fine for either of these.
2. Bad programmer: ignores the exception (smother). CE forces this behaviour.
3. Bad programmer: RTE, ignores the exception and it is observed in the stack trace. we can fix it easily!

:)

of course, this is only one thing against CE's, there is the other points of
inappropriate time to handle, and so on, as discussed in the other thread
and the links.
 

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



 
Sorry, I'm not the least bit convinced. Your arguments sound kind of strawmanish to me.

Most of my comments to you in this thread were because I thought you were talking about the same finally issues that I was. Once I realized it was the checked exception argument bleeding over from the other thread, I should've left well enough alone. I will now though. I'm not going to argue that point any more.
 

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



 
Sorry, I'm not the least bit convinced. Your arguments
sound kind of strawmanish to me.

Well i'm glad i spent that time constructing them if you are
just going to ignore them.

I won't waste my time in the future.
 

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



 
Sorry, I'm not the least bit convinced. Your
arguments
sound kind of strawmanish to me.

Well i'm glad i spent that time constructing them if
you are
just going to ignore them.

I won't waste my time in the future.

I meant no offense. I just don't see anything there to convince me of your position that checked exceptions do more harm than good. Sorry if it came out wrong.

Although (entering pedantic ballsniffing mode), if your goal is to convince me (in particular) of that point, then technically, yeah, they are a waste of time, as they're not having that effect. ;-)
 

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



 
Well i'm glad i spent that time constructing them if
you are
just going to ignore them.

And I wasn't ignoring them. I read them, but didn't find them convincing, and have decided not to respond to them anymore, because I don't think I have anthing else to say that's not either a repeat of what I said, or a waste of my time to write, or both.
 

Posts:27,518
Registered: 11/3/97
Re: Catching causal exceptions from finally{} block?  
Aug 5, 2004 7:59 AM (reply 70 of 84)



 

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.

I don't either.

But from my point of view it isn't that it helps people who don't know what they are doing but rather that it helps those that do.

Of course I don't want to eliminate checked exceptions either (but I might consider using unchecked ones the next time I create a layer from scratch.)
 

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



 
I totally don't buy into the notion

perhaps you could go short on it ? (very lame joke).

I liked it. :-)

but the process that leads to them being able to
'forget' about it
now means the exception is smothered, generally. if
they 'forgot'
about it with runtimeExceptions the errors would be
seen as they
occur, hence allowing them to be fixed.

This is true, but isn't it worse to encourage
developers not to close resources? This is an aspect
of checked exceptions I hadn't even thought of in the
other thread. Now that I think about it I'm not sure
if that's a side-effect or a central advantage of
them, and I'm too hungry to think it through.
Tomorrow, then.

Huh?

Checked exceptions and closing resources are not connected.

I don't associate it that way. And based on the posts in the JDBC forum no one else ever sees it that way either.
 

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



 
My thoughts re: checked exceptions and closing resources. You're writing your method with database access, and you put the SQL statements and all, and add the ResultSet.close(), etc. Your compiler informs you that you have exceptions to deal with, both from the db calls and the resource closings. That could prompt you to think about how to handle those exceptions, and the fact that they need to be handled in different ways. If the exceptions were not checked, you would be more likely to go on your merry way having written code that would fail to close resources in the case of an exception.

It still makes sense to me on a full stomach. Are there holes to be shot in it?
 

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



 
My thoughts re: checked exceptions and closing
resources. You're writing your method with database
access, and you put the SQL statements and all, and
add the ResultSet.close(), etc. Your compiler informs
you that you have exceptions to deal with, both from
the db calls and the resource closings. That could
prompt you to think about how to handle those
exceptions, and the fact that they need to be handled
in different ways. If the exceptions were not
checked, you would be more likely to go on your merry
way having written code that would fail to close
resources in the case of an exception.

It still makes sense to me on a full stomach. Are
there holes to be shot in it?

You mean that the close() method itself throws an exception and because of that someone might consider different strategies?

Certainly I do.

But again based on the JDBC postings a lot of other people don't. If they don't understand that there is a resource management issue there to begin with, then exceptions don't help with that.
 

Posts:6,750
Registered: 1/25/04
Re: Catching causal exceptions from finally{} block?  
Aug 5, 2004 9:08 AM (reply 74 of 84)



 
Right, this would only be a benefit to someone who already has something of a clue and just needs a reminder.
 
This topic has 84 replies on 6 pages.    « Previous | 1 | 2 | 3 | 4 | 5 | 6 | Next »