Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: caGateway crashes / use of *MustSucceed functions
From: Dirk Zimoch <dirk.zimoch@psi.ch>
To: "J. Lewis Muir" <jlmuir@anl.gov>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: 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





Replies:
RE: caGateway crashes / use of *MustSucceed functions Jeff Hill
References:
caGateway crashes / use of *MustSucceed functions Dirk Zimoch
Re: caGateway crashes / use of *MustSucceed functions J. Lewis Muir

Navigate by Date:
Prev: Re: alh1_2_24 build problem Andrew Johnson
Next: Re: caGateway crashes / use of *MustSucceed functions Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: caGateway crashes / use of *MustSucceed functions J. Lewis Muir
Next: RE: caGateway crashes / use of *MustSucceed functions Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·