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

This is a discussion on Is there a catch to return in a try/catch box? within the C++ Programming forums, part of the General Programming Boards category; It's true, but sometimes there are things that won't clean up by themselves. And it's perfect for gathering the exception ...

  1. #16
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,012
    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.

  2. #17
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    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.

  3. #18
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,012
    Quote Originally Posted by Daved View Post
    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.

    Quote Originally Posted by Daved View Post
    >> 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.

  4. #19
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    >> 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.

  5. #20
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,012
    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.

  6. #21
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    >> 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.

  7. #22
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,012
    Quote Originally Posted by Daved View Post
    >> 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.

  8. #23
    Registered User
    Join Date
    Apr 2007
    Posts
    284
    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;

    Quote Originally Posted by Daved View Post
    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).

  9. #24
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    Yes.

  10. #25
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by meili100 View Post
    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.

  11. #26
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Daved View Post
    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.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. is it ok like that?
    By ExDHaos in forum C++ Programming
    Replies: 8
    Last Post: 05-23-2009, 10:02 AM
  2. OOP Question DB Access Wrapper Classes
    By digioz in forum C# Programming
    Replies: 2
    Last Post: 09-07-2008, 05:30 PM
  3. Replies: 8
    Last Post: 03-10-2008, 12:57 PM
  4. OpenGL Window
    By Morgul in forum Game Programming
    Replies: 1
    Last Post: 05-15-2005, 01:34 PM
  5. string class errors
    By CodeMonkey in forum C++ Programming
    Replies: 13
    Last Post: 07-21-2003, 12:20 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21