Although my relationship with OpenBUGS is still in the early stages, one glaringly obvious and quite infuriating shortcoming has been the lack of detail in its error messages. The initiated amongst you are no doubt familiar with the phrase “Sorry, something went wrong in procedure [blah]”. These error messages had me chasing my tail for hours in vain attempts to find offending segments of code. Surely, I thought, there must be a way to display more detailed information about the cause of an error.
As it happens, there is.
The solution — enabling “Oberonmicrosystems’ extremely powerful trap handler” — is in fact mentioned briefly in the OpenBUGS Developer Manual. It’s straightforward enough… simply locate the file Bugs/Code/Traphandler.ocf, and rename it (e.g. to Traphandler_simple.ocf). Once the file is renamed, quit and restart OpenBUGS, which will now use the Oberonmicrosystems trap handler instead of the frustrating default handler. The result: OpenBUGS now spews forth copious amounts of information relating to an error, including the procedure that ran into the error (and its source code), and the values of all local variables in that procedure. If at any time you feel the need to revert to the original trap handler, just restore the original file name.
In the above screenshot, the trap handler indicates that OpenBUGS tripped up when it attempted to sample F[26, 5]. In this case it was because the precision parameter for the normal distribution was set to infinity (clearly the standard deviation of the distribution can’t be calculated if 1/σ2 is equal to infinity). For more elusive errors, the source code (below), which has the problem line highlighted, can help to reveal the problematic procedures, parameters or data.
More information about OpenBUGS trap windows can be found in the OpenBUGS manual.