Hi all I am pretty sure what I am doing is right, but I couldn't come up with some convincing arguements. Why would it be better to put each individual piece of code it it's own try/catch/finally as opposed to putting them into one large try/catch/finally ?
the first thing that came to mind was code breakdown,
the second was to clarify where the errors are. Are there any other big ones that I am missing ?
> Hi all I am pretty sure what I am doing is right, but
> I couldn't come up with some convincing arguements.
> Why would it be better to put each individual piece
> of code it it's own try/catch/finally as opposed to
> putting them into one large try/catch/finally ?
Would it be? I'd think it makes code barely readable. Also, maybe subsequent statements depend on the one throwing the exception so they make no sense being behind the catch block.
> the second was to clarify where the errors are.
That's what the stak trace does.
> I am basically trying to reason with myself weather
> or not I should have 2 or 3 try catches in a method
> call instead of one all en-compassing (sp) one.
> Unfortunately I can't break a couple of these
> methods down into their own calls at this time.
Why? I still don't see why having a bigger try block is a bad thing. Will the other steps be able to be executed even if the first one fails? If so, break it up. If not, don't.
> > I am basically trying to reason with myself
> weather
> > or not I should have 2 or 3 try catches in a
> method
> > call instead of one all en-compassing (sp) one.
> > Unfortunately I can't break a couple of these
> > methods down into their own calls at this time.
>
> Why? I still don't see why having a bigger try block
> is a bad thing. Will the other steps be able to be
> executed even if the first one fails? If so, break it
> up. If not, don't.
Ok thanks Rene. It seemed to me with everything that i've been learning trying to keep the smallest scope posisble should be observed but I guess that blinded me to using the largerest scope required to do the job cleanly, which was why I was asking. It seems there are to many lines that are spent dealing with exceptions in this code.
thanks again.
> Ok thanks Rene. It seemed to me with everything that
> i've been learning trying to keep the smallest scope
> posisble
Not "possible". "Feasible".
> should be observed but I guess that blinded
> me to using the largerest scope required to do the
> job cleanly, which was why I was asking.
You probably created the smallest-possible try-block, but forced yourself to declare your variables in the largest-possible scope. So it's either-or anyway.
> Hi all I am pretty sure what I am doing is right, but
> I couldn't come up with some convincing arguements.
> Why would it be better to put each individual piece
> of code it it's own try/catch/finally as opposed to
> putting them into one large try/catch/finally ?
Depends what you mean by "piece of code."
The idea behind the exception mechanism is that that your "happy path" code--the stuff you're trying to do and that you expect to work--is all together, and the stuff to handle problems--exceptions--separate from that.
step1
step2
step3
step4
handle error X
handle error Y
handle error Z
is much more readable and maintainable than
step1
if error return error code
step2
if error return error code
step3
if error return error code
step4
if error return error code
To that end, the following kind of defeats the purpose:
try {
step1
}
catch () {}
try {
step2
}
catch () {}
etc.
Generally, you probably want most of all of a method's body inside a single try/catch. Since any given method should be too terribly long, your try block won't be too terrribly long either.
This is just a rule of thumb, of course. Sometimes a method does a few things where later steps must execute even if earlier steps fail, so you might have a few small blocks that each have their own try/catch. Though, at that point, it's probably worth thinking about making each of those blocks its own method.
> Why would it be better to put each individual piece
> of code it it's own try/catch/finally as opposed to
> putting them into one large try/catch/finally ?
it's not. you're missing the whole point of what exception classes are for i think. they are for logically separating different things that can go wrong. For example, FileNotFoundException, you'd check for that when looking for a file. You don't just wrap your entire program around a try/catch block and catch one or all exceptions, you logically break it down. so again, it's not something we can get philosophical on or discuss, it depends on your code requirements.
> it's not. you're missing the whole point of what
> exception classes are for i think. they are for
> logically separating different things that can go
> wrong.
That's the reason for having different exception classes, but it's not the reason for the overall exception mechanism. The different exception classes are irrelevant to the original question as I understand ig.
> For example, FileNotFoundException, you'd
> check for that when looking for a file. You don't
> just wrap your entire program around a try/catch
> block and catch one or all exceptions, you logically
> break it down.
You don't break it down into different try statements based on what exceptions can occur. You do it based on the responsibility of the block of code in a given try block and whether code that follows textually should be executed even if the preceding code encountered an exception.
> so again, it's not something we can
> get philosophical on or discuss,
We can and I am. :-P
> here we go again, splitting hairs, you said what i
> said
No, I most certainly did not.
> but just took more time to say it and nit picked
> my post, as usual...
Technical discussions of this nature demand a certain amount of precision. You may understand what's going on, but your answer was imprecise at best and incorrect at worst. I tried to address that to avoid confusion for whoever reads this thread. No need to take it personally.
Either way, you misinterpreted what i wrote and i disagree with what you posted. I still feel my post was right on. Read it again, I said you break down try/catch LOGICALLY and you inferred that i somehow meant that you break down the code according to each exception class, which is not only ridiculous, but impossible to implement
> Either way, you misinterpreted what i wrote
If I did, then it's because you didn't express yourself clearly or precisely enough.
> and i
> disagree with what you posted.
What in particular do you disagree with? I didn't notice you disagreeing with anything that I said, but if you do, please quote it and explain why you disagree.
> I still feel my post
> was right on.
It wasn't.
> Read it again,
I did.
> I said you break down
> try/catch LOGICALLY and you inferred that i somehow
> meant that you break down the code according to each
> exception class,
Here's what you said:
> you're missing the whole point of what
> exception classes are for i think. they are for
> logically separating different things that can go
> wrong.
I agreed that that's why the exception classes exist, but it is not the main reason for the existence of the exception mechanism. The OP's post
is really more about the mechanism and best practices for using it than about the fact that you can catch specific exceptions.
As for what I you claim I inferred, no, I didn't. Again, due to the lack of precision in your post, it wasn't clear exactly what point you were trying to make. So I took a guess at the general area you were talking about and put in my own thoughts on the subject.
SoulTech, thanks for the thoughts. Jverd same to you. Here is my little quipe for this disagreement between the two of you. When I'm explaining things I am very loose with terms, as I understand what I am saying, but sometimes forget the person I am talking to may not understand. I think this is what jverd is trying to avoid. Using as precise of terms as possible means that there is the least amount of interpretation/judgement needed to understand what each is trying to convey, and because of this the least possibility of misunderstanding. On the other end of the spectrum having someone explain it without all of the specifics can allow me to get a general grasp and then refer to the specific posts in order to clarify any particulars that i didn't understand.
Thanks to all of you to help me furthur my knowledge of java, even if i'm only farther ahead in knowing how little i know ;-P
> > i'm glad you see it my way
>
> I wasn't aware that I do. Apparently your words mean
> something different than I originally though. All's
> well that ends well, I guess.
That isn't a suprise, we do also have different definitions of what animations are:
http://forum.java.sun.com/thread.jspa?threadID=5122888
> > > i'm glad you see it my way
> >
> > I wasn't aware that I do. Apparently your words
> mean
> > something different than I originally though.
> All's
> > well that ends well, I guess.
>
> That isn't a suprise, we do also have different
> definitions of what animations are:
> http://forum.java.sun.com/thread.jspa?threadID=5122888
Seems SoulTech doesn't like it when people disagree with him or correct or clarify his loose wording.
