RFR: 8348986: Improve coverage of enhanced exception messages [v11]

[Mark Sheppard]

On Mon, 26 May 2025 19:22:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:
>> 
>>> 251:             return;
>>> 252:         enhancedSocketExceptionText = SecurityProperties.includedInExceptions("hostInfo");
>>> 253:         enhancedNonSocketExceptionText = SecurityProperties.includedInExceptions("hostInfoExclSocket")
>> 
>> This looks like the inverse of the previous use of a socket category, except this time it anything that is not in Socket.
>> 
>> Consider the following: 
>> includeInException specifies the type of information that maybe included in an enhanced exception 
>> e.g. Hostname, IPAddress, PortNumber, UserDetails, Uri (including Urls), JarDetails, All
>> This defines an information policy 
>> 
>> developer are familiar with packages, so a second property specified the "domain" of application of an information policy:  enhancedException.packages specifies a list of packages where the includeInException information policy will apply
>> 
>> an empty list or the enhancedException.packages means freedom of information and the defined includedInException applies to all packages
>
>> This looks like the inverse of the previous use of a socket category, except this time it anything that not in Socket.
> 
> I think the PR has it right. No change to existing behavior. To opt-in and reveal more host information in exceptions then you can run it with configured to "hostInfo".  It does mean repurposing the name but it's a good name going forward.

The point I was raising, is that the socket etc category was dropped under the premise that it requires knowledge of the APIs used. 
But equally the setting hostInfoExclSocket suggests some knowledge of APIs is available, so there is a contradiction in the rationale presented above
Also the setting enhancedNonSocketExceptionText is inclusive of the setting enhancedSocketExceptionText, which adds further subtleties to the configuration, which was previously suggested should be avoided.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2107873149