Is there a catch?Code:try{ ... return true; }catch(...){ ... }
Is there a catch?Code:try{ ... return true; }catch(...){ ... }
Can you be more specific with your question?
The code inside the catch block will only be run if an exception is thrown by the code in the try block. If not, then the the return will execute. If no exception is thrown, the catch block code will never be run regardless of whether the return statement is there or not.
What do you mean?
Are you having a problem?
Is that to say, the code is as safe as:
Code:try{ ... }catch(...){ ... } return true;
Since the code does nothing, it has the same safety in both cases.
The best way, however, is to not have catch-all clauses at all. Use RTTI for resource management, and the situations where you need a catch-all will be very rare.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
These two pieces of code are different:Code:try{ ... return true; }catch(...){ ... }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).Code:try{ ... }catch(...){ ... } return true;
There shouldn't be any exceptions thrown in a return statement unless you're actually executing something in the return, like this:
Code:return SomeFunc(); or return new Obj;
I think he is catching an exception and then returning, not trying to catch an exception on the return.
I do not recommend returning inside of a try block but inside of a catch block you may have to.
I don't like returning mid function but sometimes it is necessary since the code beyond the try/catch block obviously assumes that the function executed succesfully. If not and you continue then the whole point of catching the exception to avoid crashing is null and void.Code:try { pSomeObject->DoSomethingThatMayThrow(); } catch (MyException &me) { ... return; }
The only other alternative is to set a boolean in the catch block and then execute an if beyond the try/catch that will exit if true and continue if false. To me though that is a lot of work just to maintain one entry one exit and may actually make the code harder to read.
Last edited by VirtualAce; 11-20-2007 at 06:39 PM.
Yes, I believe CornedBee meant RAII. The simple examples would be the use of containers that manage their own memory, and/or smart pointers.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Oops, typo. Yes, I meant RAII.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I don't find it bad at all... If, say, you have a function that return a boolean of success or failure, you could return true within your try and false within your catch.
When it's somewhat more complicated, like returning a error, or exception class, I typically have a global pointer at the start of the function, init it to NULL and if there's an error, create an object with it and at the end, after try/catch, return that var.
Otherwise, you can also return within your try if you're doing a catch/rethrow approach. Basically, if some function within your function/class fails, then the parent function catches that exception, cleans up, and rethrows it. In that case, there's no need for a return since it throws and thus I usually place a return in the try block.
I don't know... I suppose it's up to each and everyone?
>> if some function within your function/class fails, then the parent function catches that exception, cleans up, and rethrows it.
Hopefully your code is structured with RAII so that the cleanup is automatic and you don't even need a try/catch block in that function at all.