- Forum
- General C++ Programming
- try catch creation style
try catch creation style
I'm trying to make a decision with respect to creating objects inside of try blocks.
At work we have a standard to try and keep our try catch blocks as small as possible. preferable with one line in the try whenever possible. This becomes a problem though when creating an object that potentially throws within it's constructor. Since the object goes out of scope once you leave the try you either have to create a scoped_ptr which is annoying, or make your try big enough to hold all the things you want to do to that object.
What suggestions do you have for dealing with this issue?
At work we have a standard to try and keep our try catch blocks as small as possible. preferable with one line in the try whenever possible. This becomes a problem though when creating an object that potentially throws within it's constructor. Since the object goes out of scope once you leave the try you either have to create a scoped_ptr which is annoying, or make your try big enough to hold all the things you want to do to that object.
What suggestions do you have for dealing with this issue?
A decent number. Another thought was to just make it so that none of our constructors threw. Just take any code that could potentially throw and put it into a separate init method. The only negative there was it left us with an extra step we'd rather not do, but so far that seems to be better than some of the others.
It sounds like your company should re-evaluate their standards. If you're using exceptions, why only sporadically? The same error handling policy should be consist at least up to module boundaries. There is no harm in wrapping entire modules in try blocks, if that's what your design calls for.
Design to provide proper error handling; do not design with the only intent of adhering to a silly rule of thumb.
Design to provide proper error handling; do not design with the only intent of adhering to a silly rule of thumb.
the harm we're concerned about with putting entire modules in try blocks is what happens if some where down the line another method that's within that try block gets updated to throw an exception which gets unintentionally caught when it shouldn't.
Only catch what you want, then. Perhaps an extra level of inheritance in your exception classes could provide a family of caught-at-module-boundary exceptions.
Why would you catch a type of exception you don't want to? It's not like the types are limited.
We're translating code from another language over to c++ and there are some common io traps in the old language that we are throwing as exceptions like NoSuchRecord or RecordExists.
So if you have a large block of code inside a try block the realities of something being added to a method in there which throws an exception like that are better than we'd like them to be.
I suppose we could just try and do a better job of making our exceptions more unique to decrease the odds of something like that happening.
So if you have a large block of code inside a try block the realities of something being added to a method in there which throws an exception like that are better than we'd like them to be.
I suppose we could just try and do a better job of making our exceptions more unique to decrease the odds of something like that happening.
closed account (EzwRko23)
If you're using exceptions, why only sporadically? |
Because they cause often more problems than they solve? It is quite tricky to get exception safety right in C++. E.g. Google totally disallows throwing exceptions from constructors in their standards.
Apart from that, having a try-catch spanning the whole function is ok.
Last edited on
+2 moorecm
What happens if that one line in the try block calls a function which calls another function which calls another function which
calls another function which just got updated to call a new function just written, and said function throws a new exception?
The problem is unsolvable.
The more general the type that the catch catches, the more general the handling of the error must be.
the harm we're concerned about with putting entire modules in try blocks is what happens if some where down the line another method that's within that try block gets updated to throw an exception which gets unintentionally caught when it shouldn't. |
What happens if that one line in the try block calls a function which calls another function which calls another function which
calls another function which just got updated to call a new function just written, and said function throws a new exception?
The problem is unsolvable.
The more general the type that the catch catches, the more general the handling of the error must be.
Topic archived. No new replies allowed.