Hi,

Jeremias Maerki wrote:
> http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback is from the
> design phase and lists the reasons:
> - type safety
> - check mechanism to detect missing translations
> - check mechanism to make sure all necessary parameters are really dealt
> with, especially when calling the same event from multiple places.
> 
> I concede that overall the whole thing might look complex, but the end
> result makes for quite clean code on the message production side.
> 
> Adding a new event isn't a big deal at all:
> 1. Add a new method to the EventProducer interface
> 2. Run the "resourcegen" task to update the model and translations
> 3. Fill in the translation
> 
> I believe the whole thing worked out quite nicely. Only recently did I
> have a chance to make use of the event subsystem on a project where I
> needed to detect certain layout problems. That was easily done and works
> nicely. I sometimes think this whole mechanism would even warrant it own
> Apache Commons subproject.
> 
> Design discussions:
> http://markmail.org/thread/bkfrub4334pcmrjd

There is a fundamental flaw in the current design IMO: it’s not well
integrated with Java’s exception-handling mechanism. It’s not the job of
the event broadcaster to throw the exception, it’s the job of the client
code, using the normal exception mechanism. And it’s up to some
higher-level object to catch the exception (or not), route it to the
event notification system, and stop the application with an error code.

All that needs to be ensured is that a localized message can be
associated to the exception. Wether the exception should be an unchecked
exception or not is a design decision pertaining to the client code.
Also, whether there should be a dedicated severity level (fatal) for
exceptions is IMO debatable. I’d say that it’s not needed. The fact that
the application stops or not should be clear enough.

At the time of that discussion that was not entirely clear to me yet.


Vincent

Reply via email to