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