| 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: 3.15 C++ Exception classes |
| From: | Andrew Johnson <[email protected]> |
| To: | Kay-Uwe Kasemir <[email protected]> |
| Cc: | Core talk list <[email protected]> |
| Date: | Wed, 22 Feb 2006 17:39:20 -0600 |
Kay-Uwe Kasemir wrote:
The out-of-memory argument might be artificial. I see these realistic cases:1) A memory allocation fails because by accident you've tried to allocate 5GB.In that case you do have 1k left to allocate a nice looking string.
Agreed.
2) You're fully out of mem, not even 100 bytes left for the error message-> you're really stuck and I doubt any special string reader stuff will help you out,because you won't be able to print it, can't open a dialog box, can't send it to a message logger, ...You'll notice that you're out of mem, you don't need the exception to tell you anyway.
This case is not always true, for at least two reasons.1. If the routine responsible for catching the exception makes sure to reserve space in the string for any error messages before it runs the try block, then there will be no problem in doing the string conversion from the exception object. If errlog implements the StringEditor API then the string could be converted straight into the preallocated network buffer, so no memory allocation is necessary to log the problem.
2. In the stack unwinding between the throw and the catch, there may be objects being destroyed that release memory back to the system; this means that by the time we get to the exception handler there may be memory available that wasn't available at the point of the throw. As a result if we have a choice, it is better to do memory allocation in the exception handler than in the exception object's constructor.
I agree that in a client application doing complicated things like opening dialog boxes isn't likely to be possible, but for the small embedded IOC world we should try to make the system robust against memory shortages. IIRC the current iocCore software is capable of running with little or no free memory - it can't connect any new CA clients or even execute shell commands, but most records are able to carry on processing normally.
Yes, you can defer the string creation. I don't think it buys much.
I'm more concerned about the robustness-in-the-face-of-memory-starvation aspect than the efficiency - I fully accept that we shouldn't be using exceptions for normal conditions due to their complexity and performance characteristics.
I did like your idea of an exception class with a printf constructor though...
- Andrew -- There is no S in exprexxo.