AbstractMessager

[Joe Darcy]

Hi Ron,

I take it you aren't finding

     RoundEnvironment.errorRaised()
https://docs.oracle.com/en/java/javase/12/docs/api/java.compiler/javax/annotation/processing/RoundEnvironment.html#errorRaised()

to be sufficient? This will indicate an error has been raised started at 
the *next* round of annotation processing.

I would be more tempted to add some default methods like

  * warn/printWarn(CharSequence msg)
  * warn/printWarn(CharSequence msg, Element e)
  * error/printError(CharSequence msg)
  * error/printError(CharSequence msg, Element e)

Cheers,

-Joe

On 7/19/2019 1:09 PM, Ron Shapiro wrote:
> In a number of processors that I've implemented, I've wanted to wrap a 
> Messager instance to track if I've printed a diagnostic with an ERROR 
> kind so I can know to abort any generation if the inputs are invalid.
>
> There are a number of ways to do this, but what always feels like 
> would be most natural is to be able to create a ForwardingMessager of 
> some sort. I think the easiest way to do this is if there were already 
> an AbstractMessager class, so I wanted to propose adding it to the JSR 
> 269 APIs.
>
> The implementation would be rather simple, just telescoping the calls 
> with `null` arguments, just like JavacMessager works.
>
> @Override
> public void printMessage(Diagnostic.Kind kind, CharSequence msg) {
>     printMessage(kind, msg, null);
> }
>
> @Override
> public void printMessage(Diagnostic.Kind kind, CharSequence msg, 
> Element e) {
>     printMessage(kind, msg, e, null);
> }
>
> // etc
>
> Alternatively, the methods could become default methods, which is 
> probably the easiest change and doesn't introduce a new type.
>
> Does something like this make sense?