commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [jci] Handling compilation errors
Date Tue, 23 Aug 2005 13:12:33 GMT
>> I think we are facing two questions:
>> 1. Keep the ProblemHandler across compilations (and add a  
>> lifecycle) or
>>    re-create the object
> Hmm, this also depends :) For the error counter there is no problem  
> to create
> one on every compilation cycle.

You mean create counter object??

> But for the external ones passed as parameter
> you might want to use always the same.

Which is why you need to reset it
....which means a lifecycle.

> But probably this can be hidden in a
> ProblemHandlerFactory with a method getProblemHandler(). This would  
> also
> externalize the lifecycle handling - which is what I would like to  
> see ;)

Somehow I got the feeling we are
a bit running round in circles here.

What we could do is NOT to pass in
a ProblemHandler to the listener
but only provide a way to return
the compilation result.

But that more or less abandons
the original concept of the handler.

We would then have separated the
handling from the result. But
what I am asking is ...why would
you need a handler if you need
the result in the end anyway?

>> 2. Is there really a usecase where you don't need the compilation  
>> result in a
>>    ProblemHandler?
> I don't know if I understand the question correctly, but a  
> ProblemHandler not
> handling problems makes no sense.

It does handle the problem ...but
a name like ProblemConsumer would
probably make more sense.

> But a ProblemHandler might not store the
> result of the complete compilation cycle, but handle the problems  
> immediately
> like the loggers.

Even for the logging handler
you want at least the stats in
the end.


...and that's my point.


View raw message