Bug #19
closedneed exception handling mechanism
0%
Related issues
Updated by Matt Jones over 24 years ago
Some more details about this bug from Jivka and my conversation about this
topic.
We should probably have an error handling class that does something graceful
when any kind of terminating exception is encountered.
All of our code should be redesigned with a single error handling class. Then
we could work through the code and, anywhere a message is passed, throw an
exception instead that is handled by our error handler class. It would be much
cleaner. This mechanism can be used to trigger a rollback when jdbc exceptions
occur, and to display messages to the user and exit gracefully or recover when
something unexpected happens in the server.Certain errors will be undefined
behavior. But others will be normal errors that result from users inputting
values that we can't deal with. We should handle both types. We should
probably have two classes. 1) MetaCatException and 2) MetaCatErrorHandler (that
deals with the exceptions). The exception is a data structure that contains the
error info. The error handler class determines what to do with the exception
that it receives (e.g., rollback, display message, exit program, etc.).
Updated by Matt Jones about 23 years ago
WONTFIX because the exception handling is managed within each of the subsystems
of metacat, e.g., DocumentImpl handles its own exceptions.