on the message consumer side it would be nice if message handlers could
throw exceptions - this would allow "strict" handlers to immediately
cancel processing of a fo file, a more lenient handlers could just emit
warnings (similar to sax handlers), and a batch system could ignore it.

However, this would require every function which uses logging to throw a
common exception (FopFeedbackException, or something like that).


On Don, 2008-01-24 at 15:45 +0100, Jeremias Maerki wrote:
> Please see:
> There are now 3 different approaches we could take for an event
> mechanism to better inform a user (technical or real-life) of events,
> problems and progress inside FOP, per rendering run of course.
> I'd be grateful for your thoughts. I'm personally preferring the
> "extended approach" even though it's the most complex one but it
> provides ease of use once it's built and contains QA measures so we
> don't accidentally forget any message templates.
> Of course, we could add these message templates as javadoc tags (like
> the Blammo proposal, but in all languages) but that puts everything in
> one file which I'd like to avoid. As long as there are only English it's
> fine, but if the community starts producing all sorts of translations it
> could get messy.
> Blammo is interesting and gave me some ideas but it's not "there". I'm
> afraid that improving Blammo would delay the whole thing too much.
> Jeremias Maerki

Reply via email to