Include actual cause's message in various parsing exception messages

[remeio]

When timeoutString is "-2", DefaultTransactionDefinition#setTimeout method will throw IllegalArgumentException(it extends RuntimeException), we will get the error message: Invalid timeoutString value "-2" - cannot parse into int.

But actually "-2" can parse into int.

In other words, the error message cannot parse into int is just right for Integer#parseInt, so I change RuntimeException to NumberFormatException. So:

• When timeoutString is "1", just ok.
• When timeoutString is "-2", we will get: Timeout must be a positive integer or TIMEOUT_DEFAULT.
• When timeoutString is "foo", we will get: Invalid timeoutString value "foo" - cannot parse into int.

try { setTimeout(Integer.parseInt(timeoutString)); } catch (RuntimeException ex) { throw new IllegalArgumentException( "Invalid timeoutString value \"" + timeoutString + "\" - cannot parse into int"); }

[simonbasle]

@remeio thanks for the PR. There is indeed a bit of an inconsistency here, but we don't think the fix you proposed is the best approach. With the current approach, we intentionally present the erroneous timeoutString in the message. It's just that the second half of the message that becomes misleading in the -2 case.

I would suggest that instead of changing the type of exception caught, you change the exception message to replace \" - cannot parse into int with \"; " + ex. That way the message will consistently reflect the actual underlying reason.

[remeio]

Thanks, I agree with you.

[simonbasle]

yeah, looking better 👍
I was made aware that there are 3 similar cases in ScheduledAnnotationBeanPostProcessor as well (look for "- cannot parse into"). Would you like to also fix these with a similar change as part of this PR?

[simonbasle]

let's use ; as a separator since : is already part of Throwable::toString

Suggested change

	"Invalid timeoutString value \"" + timeoutString + "\": " + ex);
	"Invalid timeoutString value \"" + timeoutString + "\"; " + ex);

[remeio]

Ok, I will fix these cases together

[simonbasle]

(marking as type: bug on @jhoeller suggestion, albeit a mild one: the original exception should percolate through to the user one way or another but here it is entirely swallowed / masked)

[simonbasle]

thanks for the PR @remeio 👍