This is the ickiest part of the whole thing.
JLib is written in C++. C++ has exceptions, and so JLib used exceptions. Visualage supports exceptions. gcc, however, isn't quite so keen on exceptions, and so, slightly late in the day, I revised JLib to not rely on exceptions. Thus there is a compile-time setting to disable or enable exceptions.
When a JLib routine decides it wants to throw an exception (derived from JException), it calls jlib_throw(). This stores the exception object in the exn field in the JPM object for the current thread, along with the exception's type cookie in the type field. If the compile-time switch was set to `yes, use exceptions properly', then a pointer to the exception will also be thrown. When the library wants to clear a thread's exception (like a catch) it calls jlib_catch().
Thus: if you are using a version of JLib with exceptions disabled, you need to test the JPM::current()->exn pointer to check for library errors, and use jlib_catch().
And if you're using a version of JLib with exceptions enabled, then don't rely on the thread's exception pointer.
There is a sample called JDebug. This provides a window which displays messages from JLib at runtime. To send messages to the window, use the JTrace class.
Now, all exceptions thrown by the library have code in their constructors to write their text to the trace. Thus having the JDebug window up can be very helpful.