5 ms·

Wait, you seem to equate a runtime exception as a bug, which to me are two different but related concepts. Directly posting every single exception raised to yo

Wait, you seem to equate a runtime exception as a bug, which to me are two different but related concepts. Directly posting every single exception raised to your bug tracker is a sure fire way to flood and overwhelm you. Logging to unfuddle, to me, is the wrong way to do it. Learn proper Ops. Learn the concepts properly: logging for application monitoring and trace debugging is one thing. Posting a confirm functional bug report is another. Error detection/escalation is best left to proper tools such as nagios/zabbix where they have grouping of errors etc. Application level tracing is best left to a logging tools like sentry/logstash/new relic/etc. Use the d

cakes 11y ago
Every runtime exception as a bug would seem overwhelming. Wanting to know when runtime exceptions happen (and grouping them) is very helpful a lot of times but it seems like by itself (without context) would only get in the way of trying to parse what is and isn't really happening in some cases. Especially when trying to sort out what needs immediate attention and what needs attention at some point later.
_virtu 11y ago
What is a confirm functional bug report? What does your workflow for logging exceptions and errors look like? What sort of separation do you have between application exceptions and other types of exceptions such as database connectivity? How do either of the aforementioned exceptions/errors materialize into a bug?
- dexterbt1 11y ago
  Sorry for the typos, I was typing this on mobile. I meant "confirmed functional bug report"; and by that I mean a reproducible scenario that actually is caused by faulty code path leading to wrong result/behaviour. Usually, in my experience, bugs are ideally reported by people after some repeatable / confirmable thought-out process. If I understood you correctly, you are automatically posting every exception to your bug tracker. My point is that not all exceptions are bugs. And certainly not all bugs are discoverable through exceptions. > What sort of separation do you have between application exceptions > and other types of exceptions such as database connectivity? How do > either of the aforementioned exceptions/errors materialize into a bug? These are great questions that you should be asking while architecting / implementing / testing / running your application (i.e. whole lifecycle). Again, not all exceptions are bugs. Many, but not all exceptions are to die / crash your program. Many exceptions are definitely recoverable (unexpected input), while others are not (failed network, unreachable DB). If you are using a decent logging framework, it’s obvious that they have different levels for logging messages. FATAL/ERROR usually mean unrecoverable, while WARNINGs are typically recoverable but may prompt further investigation for the log audience, and INFO/DEBUG are generally harmless, non-error messages. This design has become widespread across many languages/frameworks and makes you ponder why. > What does your workflow for logging exceptions and errors look like? My view is that error handling is generally a delicate art and science (see why Golang doesn’t have exceptions, a decision made by veteran language designers!). I follow the principle of Fail Fast, especially for unrecoverable errors; that is, don’t hide fatal errors. Bubble up exceptions. Carefully design your layers to raise and catch the appropriate exceptions, if at all (see also Erlang’s let it crash principle). c2 wiki has some good starting discussions: http://c2.com/cgi/wiki?FailFast http://c2.com/cgi/wiki?FailFast http://c2.com/cgi/wiki?FirstRuleOfLogging http://c2.com/cgi/wiki?FirstRuleOfLogging Note, these are all abstract and conceptual, and not tool oriented. They go back to the design of your system and your processes, to fit your organization / communication structure. Also not stated is the great importance of automated tests (unit tests / integration tests / functional tests). Remember I mentioned confirmed bugs? Because at the very least, every bug discovered should have a corresponding test written to prevent regression. A decent engineering team should have good grasp and practice of many levels of automated testing. P.S. as for our tools, our stack uses logstash/elasticsearch for distributed logging + opsview/nagios NRPE for ops-related detection/escalation of issues that warrant attention.
  - _virtu 11y ago
    Thanks for the reply. I was actually looking for more of an abstract solution. Tools are great and all but building processes and architecting a better way to log bugs is more important.

cakes 11y ago

Every runtime exception as a bug would seem overwhelming. Wanting to know when runtime exceptions happen (and grouping them) is very helpful a lot of times but it seems like by itself (without context) would only get in the way of trying to parse what is and isn't really happening in some cases. Especially when trying to sort out what needs immediate attention and what needs attention at some point later.

_virtu 11y ago

What is a confirm functional bug report? What does your workflow for logging exceptions and errors look like? What sort of separation do you have between application exceptions and other types of exceptions such as database connectivity? How do either of the aforementioned exceptions/errors materialize into a bug?

dexterbt1 11y ago
Sorry for the typos, I was typing this on mobile. I meant "confirmed functional bug report"; and by that I mean a reproducible scenario that actually is caused by faulty code path leading to wrong result/behaviour. Usually, in my experience, bugs are ideally reported by people after some repeatable / confirmable thought-out process. If I understood you correctly, you are automatically posting every exception to your bug tracker. My point is that not all exceptions are bugs. And certainly not all bugs are discoverable through exceptions. > What sort of separation do you have between application exceptions > and other types of exceptions such as database connectivity? How do > either of the aforementioned exceptions/errors materialize into a bug? These are great questions that you should be asking while architecting / implementing / testing / running your application (i.e. whole lifecycle). Again, not all exceptions are bugs. Many, but not all exceptions are to die / crash your program. Many exceptions are definitely recoverable (unexpected input), while others are not (failed network, unreachable DB). If you are using a decent logging framework, it’s obvious that they have different levels for logging messages. FATAL/ERROR usually mean unrecoverable, while WARNINGs are typically recoverable but may prompt further investigation for the log audience, and INFO/DEBUG are generally harmless, non-error messages. This design has become widespread across many languages/frameworks and makes you ponder why. > What does your workflow for logging exceptions and errors look like? My view is that error handling is generally a delicate art and science (see why Golang doesn’t have exceptions, a decision made by veteran language designers!). I follow the principle of Fail Fast, especially for unrecoverable errors; that is, don’t hide fatal errors. Bubble up exceptions. Carefully design your layers to raise and catch the appropriate exceptions, if at all (see also Erlang’s let it crash principle). c2 wiki has some good starting discussions: http://c2.com/cgi/wiki?FailFast http://c2.com/cgi/wiki?FailFast http://c2.com/cgi/wiki?FirstRuleOfLogging http://c2.com/cgi/wiki?FirstRuleOfLogging Note, these are all abstract and conceptual, and not tool oriented. They go back to the design of your system and your processes, to fit your organization / communication structure. Also not stated is the great importance of automated tests (unit tests / integration tests / functional tests). Remember I mentioned confirmed bugs? Because at the very least, every bug discovered should have a corresponding test written to prevent regression. A decent engineering team should have good grasp and practice of many levels of automated testing. P.S. as for our tools, our stack uses logstash/elasticsearch for distributed logging + opsview/nagios NRPE for ops-related detection/escalation of issues that warrant attention.
- _virtu 11y ago
  Thanks for the reply. I was actually looking for more of an abstract solution. Tools are great and all but building processes and architecting a better way to log bugs is more important.