4 ms·
One of my longest and most frustrating debugging sessions was with a Java project where some developer was fed up with 100-line stack traces and wrote the follo
by q3k 6y ago
One of my longest and most frustrating debugging sessions was with a Java project where some developer was fed up with 100-line stack traces and wrote the following:
catch (Exception e) {
log.error(e);
}
Which caused the following error output
ERROR: could not connect
(mentally adjust to Java syntax, error message, don't remember off the top off my head)
I'm not joking. Having overly-verbose errors by default will make people just swallow everything at some point or another.
That particular example was triggered, IIRC, by a configuration file containing a malformed IP address, which was interpreted as a hostname, which resolved into an NXDOMAIN, which caused a magic connect-socket-to-dns-name-or-ip-address call to fail with a generic message when that socket was lazy-connected in an unrelated code path.
- theamk 6y agoYep, people keep doing this. I think it depends on background. If the app is to be used by user unfamiliar with language, and there are no robust error reporting systems -- think website or desktop app -- then this approach actually makes sense. But in the environment where most investigation is done via the logs, and many bugs are not trivially reproducible? Not so much.
- chaorace 6y agoFollowing through to the logical conclusion, you would want some way to switch between simple logs and context-rich logs. We've reinvented the verbose flag!
- merb 6y agobtw. there are error loggers which would print a stack trace in that case. i.e. slf4j. you can even do log.error(e, "blablabla");