On Mon, 23 Oct 2023 22:15:48 GMT, Uwe Schindler <uschind...@openjdk.org> wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove 2 extraneous files from commit > > Marked as reviewed by uschindler (Author). > @uschindler You may want to make the Lucene tests more robust by making them > immune to exception messages contents. > > But thanks for trying out the EA releases on important libraries like Lucene > ;-) It is important to have early feedback to gain more information before > shipping the GA release. Thanks for this. Actually this was a bad example. This was just test code, so I will more or less only remove the message check. In that case it would be enough to check for the NumberFormatException. I will provide a fix for this. This is a very old test from a not so well-maintained module. Anyways it helped a bit to make the code more clean, because the NumberFormatException is now generated in the same way everywhere which makes it more consistent. I mainly openend the iusse to inform you about that incompatibility because the exception message looks the same since very early java versions. So suddenly chaging it might bring others into the same situation like we were. I agree the spec does not enforce a message, but a more helpful message is always better than the completely empty one. So I would say, this PR is just a cleanup so "enhancement" as said by Alan Bateman is a good categorization. Thanks for the quick fix. But I will fix the issue in Lucene, too! P.S.: At other code we do not rely on exception messages. In recent code of MemorySegment we have some ambiguity with IllegalStateException when the scope of a memory segment was closed. I refused to look into the exception message and instead of parsing mesage, when catching exception, I checked if the memorysegment's scope was closed and only then convert the exception to a Lucene "AlreadyClosedException". In all other cases it was rethrowing the original exception. With exception messages you would have to look for some text string in them which is fragile. See this example: https://github.com/apache/lucene/pull/12707 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16320#issuecomment-1776967713
