Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Code execution logic  RSS feed

 
rama murthy
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am writing some code and one particular build-in method(Java-API) is causing an exception and I had enclosed it with in try/catch. I am printing the exception in catch block using SOP. After that normal execution contines.

My problem here is if an exception is caught then I want rest of the code to stop executing and goto 10 lines below the code where normal execution should continue. How to implement it

For example

public void testingMethod() {

SomeObject obj = null;

try {
obj = differentObjectInstance.getSomething();
}catch(){
SOP(Exception Caught);
}

code line 1
.
.
.
code line 10

code line 11
}

I want the program to continue with line 11 if the exception is caught.

The reason why I am getting error in line 1 code is like I am trying to invoke some methods of "obj" object which is still "null" and I endup getting NullPointerException.

obj.callAMethod();
obj.callBMethod();

I am solving this problem by setting a boolean flag like

SomeObject obj = null;
boolean b = true;

try {
obj = differentObjectInstance.getSomething();
}catch(){
SOP(Exception Caught);
b = false;
}

if(!b){
b = true;
}else{
code line 1
.
.
.
code line 10
}

code line 11
}

This logic works fine but is there a better way to handle this.
 
aslam parveez
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Include Code line1 to Code Line10 inside the try block after
obj = differentObjectInstance.getSomething();

And put Code line11 outside the try block. If you do so then if an exception is raised at "obj = differentObjectInstance.getSomething();"
control goes to the catch block and after that normal execution continues from Code Line11 which you will be putting outside try block.
 
rama murthy
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello aslam parveez

I already thought about what you said, but was NOT interested in implementing it. Bacause don't you think we are supposed to wrap only the part that causes exeception. Why to unnecessarily include so many lines of code that got nothing to do with the exception.

I hope what I had said is correct and looking for more inputs to improve the logic.
 
aslam parveez
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As long as you are interested in executing certain statements in a sequence when there is no possiblity of exception then wrapping them all inside try block is no harmful work rather than using an ugly looking flag and if condition.
 
rama murthy
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

As long as you are interested in executing certain statements in a sequence when there is no possiblity of exception then wrapping them all inside try block is no harmful work rather than using an ugly looking flag and if condition.


Yes you are correct. A boolean flag and if loop is definitely ugly. But I seriously doubt whether wrapping all the unnecessary non-exeception causing code inside try block would be a correct decision here.

I will admit as of now what you had suggested is better.
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You don't need a flag as such. Just use the value of 'obj'
 
Campbell Ritchie
Marshal
Posts: 55694
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But why are you catching a NullPointerException in the first place?

If you have such an Exception you are passing a null reference somewhere. You ought to go back there and find which object is null in the first place.

If it has a bona fide reason for being null, then you ought to be dealing with theat with an if else.
I fulminate regularly about Exceptions which ought not to be caught; here is one of my more restrained attempts.
[ June 23, 2006: Message edited by: Campbell Ritchie ]
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by rama murthy:
But I seriously doubt whether wrapping all the unnecessary non-exeception causing code inside try block would be a correct decision here.


Actually, I strongly disagree with you on this. If you have a sequence of operations which should be aborted if an exception occurs, then that's exactly what a try block is for. And as a general principle, try blocks should be as large as possible, for this makes the flow of the normal code clearer, and concentrates error handling in one place. A method broken up into fragments by tiny try blocks is very difficult to follow -- and furthermore, if such a thing is even possible, it's a sign that the method is too long and should instead be broken into multiple smaller methods.
 
rama murthy
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Joanne Neal

Thanks for your suggestion. I really like it.

Hello Campbell Ritchie

Thanks for you reply. Yes it is a local variable.

Hello Ernest Friedman-Hill

Thanks for you reply.


And as a general principle, try blocks should be as large as possible, for this makes the flow of the normal code clearer, and concentrates error handling in one place.


If this is the way to go then I will follow the same.
 
Campbell Ritchie
Marshal
Posts: 55694
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Only too glad to help. Having a look at Joanne Neal's solution, it looks not very different from what I suggested. And as you say, if your obj1 is a local variable then you do have to initialise it to null.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!