This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes exceptions used for non-local branching Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "exceptions used for non-local branching" Watch "exceptions used for non-local branching" New topic
Author

exceptions used for non-local branching

david colais
Greenhorn

Joined: Nov 15, 2010
Posts: 29
hi guys...
Exception handling mechanisms should not be used as a means of non local branching...
Can anyone explain what this sentence means with the help of an example???
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3573
    
  14

I'm not exactly sure, but if I take a guess it essentially means: Don't let the overall logic of your program depend on whether an exception has occurred. If an exception is caught, handle it by printing something, logging the error, aborting some procedure, or propagating the exception further up the stack.

In short, don't make try try catch block into some glorified if statement.
Ilari Moilanen
Ranch Hand

Joined: Apr 15, 2008
Posts: 198
I am not 100% certain if that sentence means this but someone can correct me if I am wrong

But in my opinion it means that you should not use exception mechanism to handle where your program branches.

Consider these two examples that both do basically the same thing



The first one of these examples throws an Exception even though it would have been enough just to return a boolean indicator of the situation. So the first one used an Exception to branch the flow. Exceptions should be used only if something went really wrong!
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3573
    
  14

No. I'm sorry, but I think this is a poor example.

There's no difference between things going 'wrong' and things going 'really wrong'. If something goes wrong, throw an exception.

I regard returning booleans that reflect whether the method executed successfully very questionable, and appropriate only in a select few situations.

In your example, the first way would be the correct way.
Ilari Moilanen
Ranch Hand

Joined: Apr 15, 2008
Posts: 198
Stephan van Hulst wrote:No. I'm sorry, but I think this is a poor example.

There's no difference between things going 'wrong' and things going 'really wrong'. If something goes wrong, throw an exception.

I regard returning booleans that reflect whether the method executed successfully very questionable, and appropriate only in a select few situations.

In your example, the first way would be the correct way.
I agree with you on what you say. I chose a bad name for my boolean. But I also hinted with my commented sentence "do something that can fail but it is not an error if it happens" that I was after a case where the false did not indicate error that should result in stopping the execution or something similar.

So we are not fighting against each other here Thanks for pointing out my poor use of words.

And it is also true that returning booleans fit only for a certain amount of situations. But do you mean that if there are multiple possible outcomes you should use exceptions to control the flow? I would instead return a "control object" that contains information of the situation and reserve exceptions to real errors.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3573
    
  14

What do you mean, if there are multiple possible outcomes?
Ilari Moilanen
Ranch Hand

Joined: Apr 15, 2008
Posts: 198
It is a goof question and I do not think I can give you an answer that will satisfy you.

And I also do not think anymoer that I am on right track with the subject of this thread.

But I will give an example. I have a situation that looks like this in my code

That started with the situation that the normal flow just created the object and there was a couple of different special cases that I needed to handle differently so I created exception classes for them. Since I do not use the exceptions anywhere else I considered this a bad coding practice. And now that the different cases have yet again multiplied I have many Exception classes that I do not use anywhere else. I have considered of refactoring my code to something like this
I know that this looks like something from C but I still think that the latter is better. Of course I also could just make a single Exception type that contains the details of the exception reason. But since the exceptions are not actual errors (just normal control flow) I do not want to throw exceptions at all in this situation.

Or if you have something better I will happily hear you out
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37900
    
  22
If you are trying to implement normal control of flow, you ought not to use exceptions. If you want a switch-case block depending on the return value, return ints, or better, members of an enum.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: exceptions used for non-local branching
 
Similar Threads
how to comprehend the "Non-Networked Mode" mentioned in my requirement!
Opinion: Ant for non-build related tasks
How to decide that method shoukld be static or not?
NX: db location
Architect: Is it enough...