Re:Size cost of C++ exception handling on embedded platforms
by Merad on Monday May 16, 2016 @09:48AM
(#11706207)
Not true. If you don't catch an exception, you're automatically saying that it's a problem you can't fix, and your program will be terminated. If you fail to check return codes, then your program tries to keep running in a broken state.
[ Parent
| on HN ]
Re:Size cost of C++ exception handling on embedded platforms
by TickleSteve on Monday May 16, 2016 @10:43AM
(#11706585)
You're misunderstanding...
The whole point is to never run in a broken state.... that path leads to expensive misery.
The point of resetting is to clear out bad state... if the condition has no defined recovery process then you cannot continue safely.
I'm not saying to not handle an error... I'm saying to not attempt recovery from undefined errors.
If you don't know what went wrong, don't attempt to 'handle' it... reset.
Re:Size cost of C++ exception handling on embedded platforms
by Merad on Monday May 16, 2016 @12:05PM
(#11707211)
The difference is that running in an unknown/broken state is the default when using error codes. Getting into such a state with exception handling typically requires explicit programmer action, such as the "catch everything and ignore it" pattern.
Re:Size cost of C++ exception handling on embedded platforms
by TickleSteve on Monday May 16, 2016 @03:29PM
(#11708933)
Sorry, that is just wrong headed.
What is needed is true error recovery thought, not syntax that encourages proper to just put in empty exception handlers.
Your point is arguing for error returns in my view.