I've refactored the code to allow plugins to register an
ExceptionFormatter with a session, which will allow plugin writers to
provide customization of messages derived from vendor-specific
SQLExceptions. Specifically, I introduced facade methods in ISession
that mimick the interface of IMessageHandler and pass the
ExceptionFormatter into the IMessageHandler interface methods that
accept a Throwable. At first it seemed logical to register the
ExceptionFormatter with the IMessageHandler. However, there is only
one instance of IMessageHandler (MessagePanel) that all sessions have
a reference to, so that proved unworkable. It seemed logical to allow
Sessions to have a default exception formatter that a plugin can
override. So that is what I went with. Of course, when working
outside the context of a Session, the IMessageHandler interface can be
given null for the ExceptionFormatter and it will use it's own default
ExceptionFormatter. When more than one plugin attempts to override
the ExceptionFormatter for a given Session, the first one to do so
wins and any thereafter result in an error message. The most
noticeable change will be for showing messages in the MessagePanel.
No longer will you do this:
} catch (SQLException ex) {
_session.getMessageHandler().showErrorMessage(ex)
}
But instead you will do this:
} catch (SQLException ex) {
_session.showErrorMessage(ex)
}
Same arguments as before, just not going directly to the
IMessageHandler. Again, this was necessary to allow the Session to
pass it's custom ExceptionFormatter (if any) to the new
IMessageHandler interface methods that accept Throwable and
ExceptionFormatter.
As before, this can be bypassed by going directly to Application and
getting the IMessageHandler - however, this should be done sparingly
as it prevents plugins from formatting exceptions and potentially
providing users with more information about the root cause of the
problem causing the exception.
Rob Manning
|