Re: [jci] Handling compilation errors

[Torsten Curdt]

I think we are facing two questions:


   re-create the object

1. Keep the ProblemHandler across compilations (and add a lifecycle) or

one on every compilation cycle.

Hmm, this also depends :) For the error counter there is no problem to create

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?

handling problems makes no sense.

I don't know if I understand the question correctly, but a ProblemHandler not

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

But a ProblemHandler might not store the

like the loggers.

result of the complete compilation cycle, but handle the problems immediately

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

YOU ALWAYS NEED THE COMPILATION RESULT

...and that's my point.

cheers
--
Torsten

PGP.sig
Description: This is a digitally signed message part