Hacker News Reader

Comment by vbezhenar | Hacker News Reader

It's funny how people like to bash long Java stacktraces, while they help immensely in the situations like these. It's obvious from the start where the error is and all those stacks can help you to find out every little detail that lead to the problem.

View on HN

I’m only familiar with people bashing long Java stack traces because (1) they are often hilariously long, with stateless web applications dumping tenfold the frames of a crashing webbrowser, (2) they contain some number of abstract factory beans (contributing to the length problem) and (3) they show up far more frequently in user-facing applications than just about any other language. Stack traces are great, gratuitous abstraction, buggy code, and exposing stack traces to users are not great.

The stack traces tend to be useful when there is a programming error in your program, and less useful when there is any other type of error. In Go, programming errors usually panic which will print a stack trace by default.

But I’ll see Java programs that give me stack traces just because I’ve misconfigured them, or the server is down, or I have a bad network connection, or a file is missing. This is awful UX. Worse, the stack trace might not tell me WHICH file is missing, or WHICH server is down.

You only get good UX for errors by manually annotating context in the places in your code where the context is known.

(My personal experience is that FAR too many actual Java programs in the wild will give me a stack trace when they should give a short error message.)

Reply on news.ycombinator.com