undefined | Better HN

0 pointsdeepsun2mo ago0 comments

I hate when tools only produce generic "TLS Handshake failed" instead of saying why exactly it failed, where is the problem.

0 comments

10 comments · 2 top-level

thunky2mo ago· 5 in thread

Sounds like you'd both be happy if the tool produced both.

deepsunOP2mo ago

And Java typically does produce both (see Exception "cause" field). So when an exception stack trace is printed it's actually list of stacktraces, for each "cause". You can skip stacktraces and just concatenate causes' messages (like people often do in Go).

So the full message would be like "Cannot add item X to cart Y: Error connecting to warehouse Z: Error establishing TLS connection to example.com 127.0.1.1: PKIX failed".

Geezus_422mo ago

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

iamcalledrob2mo ago

People give Go's error handing a lot of flak, but I personally love the errors that come out of a quality codebase.

Just like your example: single line, to the point and loggable. e.g.

  writing foo.zip: performing http request (bar.com): tls: handshake: expired certificate (1970-01-01)

Exceptions with stack traces are so much more work for the reader. The effort of distilling what's going on is pushed to me at "runtime". Whereas in Go, this effort happens at compile time. The programmer curates the relevant context.

1 more reply

appplication2mo ago

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.

Geezus_422mo ago

A stack trace that is >10 pages in less is not what I would call minimal.

1 more reply

kitd2mo ago· 3 in thread

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).

gf0002mo ago

This couldn't be further from the truth.

There is no ecosystem I would choose over Java when it comes to observability and it's not even close.

Good luck finding your segfault, oom, race condition or just simply lazy logging culture bug with a C/go codebase at 3am.

I will happily see my proper stack trace, heap dump, or connect directly to prod with a debugger with basically no performance penalty.

kitd2mo ago

Your stack trace tells you where in the code the error occurred, but doesn't tell you what it was doing with what data. For that you need to pass context for the error up the chain of calls, adding to it as you go up. Exceptions are not a great way of doing it as you only have the local context, which isn't a great help when you're catching N levels up.

And if you're not catching N levels up but catching at each level, then you are emulating error values but with try/catch blocks.

Geezus_422mo ago

That is great for you as a developer. As a sysadmin supporting other people's crap, stack traces and heap dumps are useless beyond forwarding them to the vendor.

j / k navigate · click thread line to collapse

0 comments

10 comments · 2 top-level

thunky2mo ago· 5 in thread

Sounds like you'd both be happy if the tool produced both.

deepsunOP2mo ago

So the full message would be like "Cannot add item X to cart Y: Error connecting to warehouse Z: Error establishing TLS connection to example.com 127.0.1.1: PKIX failed".

Geezus_422mo ago

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

iamcalledrob2mo ago

People give Go's error handing a lot of flak, but I personally love the errors that come out of a quality codebase.

Just like your example: single line, to the point and loggable. e.g.

  writing foo.zip: performing http request (bar.com): tls: handshake: expired certificate (1970-01-01)

1 more reply

appplication2mo ago

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.

Geezus_422mo ago

A stack trace that is >10 pages in less is not what I would call minimal.

1 more reply

kitd2mo ago· 3 in thread

The difference really becomes apparent when trying to debug a customer's problem at 3am (IME).

gf0002mo ago

This couldn't be further from the truth.

There is no ecosystem I would choose over Java when it comes to observability and it's not even close.

Good luck finding your segfault, oom, race condition or just simply lazy logging culture bug with a C/go codebase at 3am.

I will happily see my proper stack trace, heap dump, or connect directly to prod with a debugger with basically no performance penalty.

kitd2mo ago

And if you're not catching N levels up but catching at each level, then you are emulating error values but with try/catch blocks.

Geezus_422mo ago

That is great for you as a developer. As a sysadmin supporting other people's crap, stack traces and heap dumps are useless beyond forwarding them to the vendor.

j / k navigate · click thread line to collapse