Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Wed, 18 May 2011 17:35:22 +0200

J. Lewis Muir wrote:

On 5/18/11 7:21 AM, Dirk Zimoch wrote:

Therefore I propose to remove all *MustSucceed functions from
future EPICS releases and allow and require proper error
handling by the application.

Any opinions on this topic?

Hi, Dirk.

What about the *MustCreate, *MustWait, and *MustLock functions?

  epicsEventMustCreate
  epicsEventMustWait
  epicsMutexMustCreate
  epicsMutexMustLock
  epicsThreadMustCreate

On a related note, I didn't look at all of them, but some of
these (e.g. epicsEventMustWait) are implemented as macros that
just do an assert on the return status of the regular non-must
function.  Others (e.g. POSIX epicsEventMustCreate) are actual
functions, but they too just do an assert.  If assertions are
disabled, this will do nothing and hence seems broken to me.  No?

Hi Lewis,

Yes. This is know as a "Heisenbug" (or the opposite?): bugs that go away

(or appear) as soon as you switch on debugging. The behavior of the

program should not change when assertions are switched on.

The idea of assert is to catch situations that "can never happen", as a

part of the defensive programming paradigm. This may show hidden

programming errors.

It is not the idea of assert to handle run-time problems like missing

external resources, e.g. heap memory.

Example: epicsEventMustWait fails if the event id is invalid. This is a

good application of assert because it should never happen if the program

is correct.

epicsEventMustCreate fails if the system is out of memory. This is a bad

application of assert because it may fail due to external influences

even though the program is correct. However, it would be a good

application of abort, assuming it is only called during startup. But who

knows? Better call epicsEventCreate and handle failing resources by

passing a proper error code back to the caller. Using assert here is

extremely bad because if assertion is disabled, the error is not handled

at all and will cause problems later.

Dirk

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System