3 ms·

.. except in Java and Python, where you also get 100-line stack trace in your error log. Or C/C++, where you get a full coredump with program state as long as y

• 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 ago
    Yep, 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 ago
      Following 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 ago
    btw. there are error loggers which would print a stack trace in that case. i.e. slf4j. you can even do log.error(e, "blablabla");