Handling exceptions

[ahjiang]

Lets say i have this method

int foo() {
try {
do something;
return SUCCESS;
}catch(Exception e){
print e;
}finally{
return FAILURE;
}
}

I understand that failure will always be returned because of the
finally clause.
What is the best practice to return a value if success or failure.
Or should the exception be propagated to the calling method?

Appreciate any advice

 

[hiwa]

Lets say i have this method

int foo() {
try {
do something;
return SUCCESS;
}catch(Exception e){
print e;
}finally{
return FAILURE;
}
}

I understand that failure will always be returned because of the
finally clause.
What is the best practice to return a value if success or failure.
Or should the exception be propagated to the calling method?

Appreciate any advice

return FAILURE; should be in the catch clause.
Your finally clause is not necessary.

 

[Helmut Leininger]

return FAILURE; should be in the catch clause.
Your finally clause is not necessary.

Or with only one return statement per method (there is only one exit
point - you cannor overlook it when making modifications):

int foo() {
int retval = SUCCESS;
try {
do something;
}catch(Exception e){
print e;
retval = FAUILURE;
}
return retval;
}

 

[Tom Hawtin]

int foo() {
try {
do something;
return SUCCESS;
}catch(Exception e){
print e;
}finally{
return FAILURE;
}
}

I understand that failure will always be returned because of the
finally clause.
What is the best practice to return a value if success or failure.
Or should the exception be propagated to the calling method?

Use exceptions for fault reporting. Return values are often difficult
for client code and have a long history of being ignored (for instance
in a live system the cd command failed one day in `cd xyz ; rm -rf *`).
Also you wont be able to use a return value (sensibly) if it is already
used to signal faults.

If you must return an error status, write it something like:

BarErrorStatus foo() {
try {
do something;
return BarErrorStatus.SUCCESS;
} catch (SomeException exc) {
// [ Or something at least a little descriptve. ]
return BarErrorStatus.FAILURE;
}
}

If you use a variable for status for some reason (for instance for use
in code following the try/catch/finally), if you leave it unassigned
until as late as possible, you can use the definite
assignment/unassignment rules to catch errors:


void foo() {
BarErrorStatus errorStatus;
try {
do something;
errorStatus = BarErrorStatus.SUCCESS;
} catch (SomeOtherException exc) {
exc.printStackTrace(); <-- Compiler error.
} catch (SomeException exc) {
// [ Or something at least a little descriptve. ]
errorStatus = BarErrorStatus.FAILURE;
}
if (errorStatus == BarErrorStatus.SUCCESS) {
blah;
}
}


It is (or should be) rare to catch
Exception/Throwable/Error/RuntimeException.

Sometimes, you do need a status flag:

Connection openConnection() throws ConnectionException {
boolean succeeded = false;
Connection raw = new RawConnection(someField);
try {
Connection buffered = new BufferedConnection(raw);
succeeded = true;
return buffered;
} finally {
if (!succeeded) {
raw.close();
}
}
}

(Although most people seem to like to leak resources instead...)

Tom Hawtin

 

[Adam Maass]

Lets say i have this method

int foo() {
try {
do something;
return SUCCESS;
}catch(Exception e){
print e;
}finally{
return FAILURE;
}
}

I understand that failure will always be returned because of the
finally clause.
What is the best practice to return a value if success or failure.
Or should the exception be propagated to the calling method?

Generally speaking, my preference would be to propagate some sort of
exception rather than return a success code.

Your method would then look something like this:

void foo() throws FooException {
try {
do something;
} catch (SomethingException e) {
throw new FooException(e);
}
}


The caller of the method need not write code like this:

if(foo() != SUCCESS){
recover
}
more stuff

(This hides the fact that foo() is being called inside a conditional, and
places the recovery code -- which isn't necessarily the main flow of the
program -- right next to the callpoint.)


But instead the calling code looks more like:

try{
foo();
more stuff
} catch (FooException e) {
recover
}

(This makes the call to foo() about as explicit as can be, and the recovery
code is nicely isolated, away from the main flow of the program.)



OK, now for quibbling:

I generally like the exceptions approach for those situations that are truly
exceptional -- making it worth your while to abruptly terminate your caller
and force it to do something it wouldn't usually. If instead, there are a
variety of situations that can normally be expected to happen, and your
caller should be expected to know about and handle them all, then returning
some sort of status code is just fine in my book. What's more appropriate
depends on the situation and is something of a judgment call in any case.

What really gets my goat is "catch Throwable" or its only slightly less
pernicious twin, "catch Exception". These are too general and should almost
never be written.

-- Adam Maass