szhorvat/LTemplate

Could handleUnknownException have a way to toggle the default message?

ghurstunither opened this issue · 3 comments

The library I'm linking with always provides a detailed description when an exception is thrown. So any message I can back in the front end looks something like

Unknown exception caught in class::func(). The library may be in an inconsistent state. It is recommended that you restart the kernel now to avoid instability.
RuntimeError: (some detailed description)

The first line makes it look like something severe happened, but then the second explains what actually went wrong.

What is the rationale behind displaying the default message when one is already provided?

The intention is that only mma::LibraryError exceptions should be allowed to reach the top level. Any other exception will be due to a programming error (a bug, that should be fixed in the C++ code). Early versions of LTemplate did not even try to handle other exceptions, and uncaught exceptions would simply crash the kernel. handleUnknownException() is an attempt to do better: try to recover, and at least print some information that may be useful for debugging.

However, when a function is aborted in the middle due to an unexpected situation, many other things could go wrong. Internal data structures of the library may be left in an inconsistent state. The next function call may indeed cause a crash. Whether this can happen depends on how your library works and what persistent internal data structures it uses.

The message that is printed is intended for the end user of Mathematica packages, not for programmers. You, as the programmer, might be able to tell what went wrong from the second message. But someone who does not know C++ and does not know how the library works internally cannot. Thus, it is important to make people aware that we just managed to avoid a full kernel crash, but there is no guarantee about what might happen next. They should save their work and restart the kernel.

The key point is: do not allow any other exception than LibraryError to leave the top level. It is your responsibility to catch those exceptions. If they are "safe", you can re-throw a LibraryError, which is the standard mechanism to report errors in LTemplate.


As for customizing the message printed by handleUnknownException() to fit your package better, that might make sense in some situations, and we could make that happen.

Internal data structures of the library may be left in an inconsistent state. The next function call may indeed cause a crash. Whether this can happen depends on how your library works and what persistent internal data structures it uses.

It is your responsibility to catch those exceptions. If they are "safe", you can re-throw a LibraryError, which is the standard mechanism to report errors in LTemplate.

I see, thanks!

All that said, feedback and ideas are always welcome. I am never certain if anyone else is using LTemplate at all, especially after the release of LibraryLink Utilities (which you should check out). Apart from some personal projects, I mainly use LTemplate as the foundation for IGraph/M, so there is a risk that it might become too specialized for that purpose. If I am aware of other users, I can try to take their use cases into account as well.