What should we put in generated documentation in place of a bad snippet?

Jonathan Gibbons jonathan.gibbons at oracle.com
Mon Sep 6 22:21:31 UTC 2021


As for "red", it should be a new CSS style, with a name like `error` 
that is configured in the stylesheet to have some culturally appropriate 
rendition.

-- Jon

On 9/6/21 3:20 PM, Jonathan Gibbons wrote:
> If we can't interpret it, don't.
>
> If the user pushes the code beyond the point where javadoc would 
> normally stop, I suggest we should output the contents of the 
> ErroneousTree "as is", perhaps with a metaphorical blinky-red border.  
> The same argument might (should?) go for any ErroneousTree.
>
> -- Jon
>
>
> On 9/6/21 8:25 AM, Pavel Rappo wrote:
>> I cannot recall any conversation on what to put in generated 
>> documentation in place of an erroneous construct in a doc comment. 
>> The ongoing work on JEP 413 (Snippets) reminded me of that problem. 
>> Although it's by no means unique to snippets, here I only consider 
>> snippets.
>>
>> If for whatever reason a snippet cannot be output, what should be 
>> displayed instead of it? It should go without saying that in such a 
>> case javadoc must generate an error for the author to see and fix. 
>> But then again, authors don't always pay attention to errors, much 
>> less warnings, coming out of javadoc (tool). I've seen that many 
>> times. So it's only reasonable to plan for what to do when (not if) 
>> such mistakes slip through the author' fingers.
>>
>> I think we need a clear indication to the reader that this is not 
>> what they should've seen. Currently, we display the "bad snippet" 
>> text using a regular snippet decoration. I think we might need to do 
>> more than that. Maybe we could use a different color (red?) theme 
>> such that it couldn't be changed from within a snippet tag.
>>
>> Thoughts?
>>


More information about the javadoc-dev mailing list