--- Comment #8 from Jeremias Maerki <>  2009-03-24 10:24:51 
PST ---
(In reply to comment #7)
> Created an attachment (id=23407)
 --> ( [details]
> Proposed patch
> Would the attach patch solve the problem in a good way?

I think you're doing pretty much the same thing I did there, only in reverse. I
specified the event for FATAL level, and "canRecover" can lower the severity to
WARN. Your change would set the default level to WARN and increase it to ERROR
if it's error-on-overflow. The only difference is that the error cause used
FATAL before and uses ERROR after the change which would effectively not stop
the formatting and allow the user to increase the event severity to FATAL if he
so chooses. You could skip the isError attribute and just set all overflow
events to ERROR level by default (Javadoc @event.severity). That would have the
same effect. Don't forget that the block-container case is not the only
overflow where an error is possible. As I said before I'm not opposed to
lowering FATAL to ERROR for "error-if-overflow". A custom event handler can
always throw an exception.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to