undefined | Better HN

0 pointsthunky28d ago0 comments

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

0 comments

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_4228d 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

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

gf00027d ago

What?

What you write makes zero sense, see my comment here: https://news.ycombinator.com/item?id=47750450

And come on, skipping 5 lines and only reading the two relevant entries is not "much work". It's a feature that even when developers eventually lazied out, you can still find the error, meanwhile you are at the mercy of a dev in go (and due to the repeating noisy error handling, many of the issues will fail to be properly handled - auto bubbling up is the correct default, not swallowing)

iamcalledrob27d ago

Different strokes for different folks.

The Go errors that I encounter in quality codebases tend to be very well decorated and contain the info I need. Much better than the wall of text I get from a stack trace 24 levels deep.

1 more reply

appplication28d 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_4227d ago

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

deepsun26d ago

And that's why you should have multiple appenders. So in code you write "log.error("...", exception)" once, but logging writes it in parallel to:

   1. STDOUT for quick and easy look, short format.
   2. File as JSON for node-local collectors.
   3. Proper logging storage like VictoriaLogs/Traces for distributed logging.

Each appender has its own format, some print only short messages, others full stacktraces for all causes (and with extra context information like trace id, customer id etc). I really think STDOUT-only logging is trying to squeeze different purposes into one unformatted stream. (And Go writing everything to STDERR was a really strange choice).

https://www.baeldung.com/logback#bd-appenders

Geezus_4224d ago

Cool. Convince your fellow Java developers to do that and I'll quit complaining about the awful errors every Java app produces.

j / k navigate · click thread line to collapse

0 comments

deepsun26d 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_4228d 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

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

gf00027d ago

What?

What you write makes zero sense, see my comment here: https://news.ycombinator.com/item?id=47750450

iamcalledrob27d ago

Different strokes for different folks.

The Go errors that I encounter in quality codebases tend to be very well decorated and contain the info I need. Much better than the wall of text I get from a stack trace 24 levels deep.

1 more reply

appplication28d 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_4227d ago

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

deepsun26d ago

And that's why you should have multiple appenders. So in code you write "log.error("...", exception)" once, but logging writes it in parallel to:

   1. STDOUT for quick and easy look, short format.
   2. File as JSON for node-local collectors.
   3. Proper logging storage like VictoriaLogs/Traces for distributed logging.

https://www.baeldung.com/logback#bd-appenders

Geezus_4224d ago

Cool. Convince your fellow Java developers to do that and I'll quit complaining about the awful errors every Java app produces.

j / k navigate · click thread line to collapse