Project

General

Profile

Bug #19

need exception handling mechanism

Added by Jivka Bojilova over 19 years ago. Updated over 17 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
metacat
Target version:
Start date:
06/12/2000
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
19

Description

It should have been assigned to


Related issues

Blocked by Metacat - Bug #17: DBWriter uses multiple transactions to load documentResolved06/08/2000

History

#1 Updated by Matt Jones over 19 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.).

#2 Updated by Matt Jones over 19 years ago

Transfer ownership to jones

#3 Updated by Matt Jones about 18 years ago

WONTFIX because the exception handling is managed within each of the subsystems
of metacat, e.g., DocumentImpl handles its own exceptions.

#4 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 19

Also available in: Atom PDF