Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · 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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System