Thread: Is there a catch to return in a try/catch box?

It's true, but sometimes there are things that won't clean up by themselves. And it's perfect for gathering the exception and doing something with it such as adding a stack trace.

But that really defeats the purpose of exceptions (adding extra try/catch blocks that rethrow the exception).

>> but sometimes there are things that won't clean up by themselves.
Understood, but in many cases that just means a little more work to make them.

Originally Posted by Daved

But that really defeats the purpose of exceptions (adding extra try/catch blocks that rethrow the exception).

Not always. Not when the class is supposed to throw an exception if something goes wrong.
If a parent function notices something goes wrong and needs to clean up (freeing some allocated memory for example), then it's ideal for it to catch the exception, clean up what it needs to, then rethrow it. That's because the class shouldn't handle the exception, but the caller and user of the class is supposed to.
The parent function or class simply cleans up after itself.

Originally Posted by Daved

>> but sometimes there are things that won't clean up by themselves.
Understood, but in many cases that just means a little more work to make them.

That's also life, and especially applies to things such as resources in Windows programming.

>> If a parent function notices something goes wrong and needs to clean up (freeing some allocated memory for example)

The parent function should have all resources wrapped in RAII so that they are appropriately cleaned up automatically if an exception is thrown from anywhere in the function. Even resources in Windows programming can be wrapped to clean up automatically.

You should strive to only catch the exception if you actually do something to handle it.

This makes code more robust. If in the future, the child function is expanded and can throw another type of exception, then the parent function doesn't need to be changed because it can already be safely cleaned up automatically. In general, there will be many "parent functions" and none of them would need to be changed and they can all avoid any type of try/catch. The code is cleaner and safer.

True enough - but I'm sure you will find that there are times that you might want to catch the exception - adding debug information why it failed, for example. Stack trace or whatever.
I suppose resources and stuff could be wrapped in classes to automatically free, them, but... sometimes it's also difficult if you're writing a smart pointer (you shouldn't wrap the memory you're handling in your own class).

But the different exceptions is an easy one. Construct and throw a single class type for every error your function/class generates. That way, you can catch that type and you won't have to worry if you're adding more errors later.
You could also make a warning class to take care of any warnings generated.

You may have a point, but I still agree on that you might catch and exception if you want to work with it (though not handle it). Add something, modify something, or whatever, then rethrow it to let someone else handle it.

>> Construct and throw a single class type for every error your function/class generates. That way, you can catch that type and you won't have to worry if you're adding more errors later.

I agree with this, but if you're catching and rethrowing exceptions along the way then it requires more catch block at each step. If you just catch the exception where it can be handled, the intermediate functions need not be modified.

If you really did have a lot of catch and re-throws, you'd want to derive your exception classes from a common base class so that you could use one catch for each exception type.

Originally Posted by Daved

>> Construct and throw a single class type for every error your function/class generates. That way, you can catch that type and you won't have to worry if you're adding more errors later.

I agree with this, but if you're catching and rethrowing exceptions along the way then it requires more catch block at each step. If you just catch the exception where it can be handled, the intermediate functions need not be modified.

Of course, it's to be done only if absolutely necessary to your implentation, since it also makes the code more error prone with mistakes.

The following 2 pieces of code are the same, aren't they?

Code:

try{
...
return true;
}catch(...){
...
return false;
}

Code:

try{
...
}catch(...){
...
return false;
}
return true;

Originally Posted by Daved

These two pieces of code are different:

Code:

try{
...
return true;
}catch(...){
...
}

Code:

try{
...
}catch(...){
...
}
return true;

The first does not return anything from the function if an exception is caught (unless there is a return statement somewhere else in the code not shown). The second one will always return true whether an exception is thrown or not (unless there is a return statement somewhere else in the code not shown).

Yes.

Originally Posted by meili100

The following 2 pieces of code are the same, aren't they?

Code:

try{
...
return true;
}catch(...){
...
return false;
}

Code:

try{
...
}catch(...){
...
return false;
}
return true;

Yes, they should act the same.

Originally Posted by Daved

But that really defeats the purpose of exceptions (adding extra try/catch blocks that rethrow the exception).

>> but sometimes there are things that won't clean up by themselves.
Understood, but in many cases that just means a little more work to make them.

I've gotten into the habit of using RAII classes for everything that needs to be deleted, closed...

BTW, the AutoPtr template I wrote can be used for any type of RAII, not just pointers. Just pass a Deletor object that releases the resource appropriately.