| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 <2011> 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 <2011> 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: caGateway crashes / use of *MustSucceed functions |
| From: | Dirk Zimoch <[email protected]> |
| To: | "J. Lewis Muir" <[email protected]> |
| Cc: | "[email protected]" <[email protected]> |
| 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