Comment by Geezus_42
5 hours ago
As a sysadmin, not developer, I hate Java almost as much as Windows. The error messages Java apps produce are like coded messages that you have to decipher.
I.E. Instead of "<DOMAIN> TLS Handshake failed" it will be something like "ERROR: PKIX failed". So now I have to figure out that PKIX is referring to PKI and it would make too much sense to provide the domain that failed. Instead I have to play the guessing game.
I hate when tools only produce generic "TLS Handshake failed" instead of saying why exactly it failed, where is the problem.
This is the kind of scenario that is served better by Go/C-style error values than exceptions. Error values facilitate and encourage you to log what you were doing at the precise point when an error occurs. Doing the same with exceptions idiomatically often requires an exception hierarchy or copious amounts of separate try/catches.
The difference really becomes apparent when trying to debug a customer's problem at 3am (IME).
Sounds like you'd both be happy if the tool produced both.
Sounds to me that deepsun and I are in agreement that an error message should tell you what the actual error was.
I.E. ERROR: TLS handshake failed: <DOMAIN> certificate chain unverified
This is why stack traces exist. But I agree Java seems to not really have a culture of “make the error message helpful”, but instead preferring “make the error message minimal and factual”.
For what it’s worth, the rise of helpful error messages seems to be a relatively new phenomenon the last few years.
So your issue isn't with Java, just with shit error messages and devs clearing the exception stack.