• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

exceptions used for non-local branching

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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???
 
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 199
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 199
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What do you mean, if there are multiple possible outcomes?
 
Ilari Moilanen
Ranch Hand
Posts: 199
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic