not really, all my point was, was just that if theexception had notbeen checked,

Which exception?

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

then (assuming no try/catch at all) thefirst exceptionwould be observed and the solution (i.e. invalidconnection stringor bad query, or whatever) could've been resolved.

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

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

perhaps itwould've been as wellthought out as jverds finally-exception-chaining

code,

perhaps not. but it wouldbe more thought out (because there is no reason toimplement try/catchin 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 allexeptions unchecked would lead to better exceptionhandling. The same people who shortcut exceptionhandling now just to get code to compile would eitherignore it altoghether given the opportunity, or wouldforget to put it in "later" just as they're forgettingto fix their exception handling "later" now,

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

but the process that leads to them being able to'forget' about itnow means the exception is smothered, generally. ifthey 'forgot'about it with runtimeExceptions the errors would beseen as theyoccur, 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? If there's no try/catch at all then the firstexception 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 checkedor not.

no it isn't. if the exception is checked, and themethod 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 itnow means the exception is smothered, generally. ifthey 'forgot'about it with runtimeExceptions the errors would beseen as theyoccur, 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.

This is true, but isn't it worse to encouragedevelopers not to close resources? This is an aspectof checked exceptions I hadn't even thought of in theother thread. Now that I think about it I'm not sureif that's a side-effect or a central advantage ofthem, 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.

Huh? If there's no try/catch at all then the firstexception 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 themethod does not"throws Exception", then a try/catch is required.

Then the exception is observed by being caught or bybeing declare to be thrown from the method. Ifsomebody writes a crappy handler here, they can justas easily write a crappy handler for the uncheckedexception further up the chain,

why would anyone ever write a crappy handler for an uncheckedexception ?

there is no point.

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

but the process that leads to them being able to'forget' about itnow means the exception is smothered, generally. ifthey 'forgot'about it with runtimeExceptions the errors would beseen as theyoccur, hence allowing them to be fixed.

But you never know when that will happen, so you'renot necessarily any better off. You're advocatingremoving a useful language feature because it mightlead to detection of errors that are otherwise hiddendue to programmer's errors in using that feature.

yep.

Also, keep in mind, if you smother a checkedexception, chances are it will manifest itself as anunchecked one at some point anyway, or at the veryleast, improper behavior.

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

but the process that leads to them being able to'forget' about itnow means the exception is smothered, generally. ifthey 'forgot'about it with runtimeExceptions the errors would beseen as theyoccur, hence allowing them to be fixed.

This is true, but isn't it worse to encouragedevelopers not to close resources? This is an aspectof checked exceptions I hadn't even thought of in theother thread. Now that I think about it I'm not sureif that's a side-effect or a central advantage ofthem, and I'm too hungry to think it through. Tomorrow, then.

I don't think it does ... it encourages them to implement their ownerror handling. they can still close the resource, they are just notrequired 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. butat least if they don't do it the exception doesn't get smothered if theyhave 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 ofinappropriate time to handle, and so on, as discussed in the other threadand the links.

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.

Well i'm glad i spent that time constructing them ifyou arejust 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.

I totally don't buy into the notion that making allexeptions unchecked would lead to better exceptionhandling. The same people who shortcut exceptionhandling now just to get code to compile would eitherignore it altoghether given the opportunity, or wouldforget to put it in "later" just as they're forgettingto fix their exception handling "later" now, or wouldhandle them incorrectly due to the same general lackof understanding that causes them to handle checkedexceptions 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.)

but the process that leads to them being able to'forget' about itnow means the exception is smothered, generally. ifthey 'forgot'about it with runtimeExceptions the errors would beseen as theyoccur, hence allowing them to be fixed.

This is true, but isn't it worse to encouragedevelopers not to close resources? This is an aspectof checked exceptions I hadn't even thought of in theother thread. Now that I think about it I'm not sureif that's a side-effect or a central advantage ofthem, 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.

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?

My thoughts re: checked exceptions and closingresources. You're writing your method with databaseaccess, and you put the SQL statements and all, andadd the ResultSet.close(), etc. Your compiler informsyou that you have exceptions to deal with, both fromthe db calls and the resource closings. That couldprompt you to think about how to handle thoseexceptions, and the fact that they need to be handledin different ways. If the exceptions were notchecked, you would be more likely to go on your merryway having written code that would fail to closeresources in the case of an exception.

It still makes sense to me on a full stomach. Arethere 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.