I'm glad this question was asked some time ago, and Thanks to @coderama for offering a bounty for this. I make questionnaires/challenges to Druplars in my local community, and this was a question there.
PHP allows you to set error and exception handlers. This similar to how you register class autoloaders and shutdown functions.
Sets a user function (error_handler) to handle errors in a script.
This function can be used for defining your own way of handling errors
during runtime, for example in applications in which you need to do
cleanup of data/files when a critical error happens, or when you need
to trigger an error under certain conditions (using trigger_error()).
Also, you can set an exception handler to handle uncaught exceptions. See
Sets the default exception handler if an exception is not caught
within a try/catch block. Execution will stop after the
exception_handler is called.
Drupal takes over these two when it initializes the environment. even before bootstrapping advanced bootstrap levels, such as the database, variables, and full bootstraps.
If the error happens in Drupal-handled request, it will be handled by either of these handlers (error or uncaught exception handler) unless it was overriden by other modules (Devel's error handler, and other error handling modules or server-side implementations, possibly New Relic).
Both of these functions call
_drupal_log_error() to proceed to the logging behavior in Drupal.
The default error handling (and other logging) functionality is based on the
watchdog() function invokes
hook_watchdog(), which the db_log module implements
hook_watchdog to store them in the database.
watchdog() function itself is not storing them in the database. Similarly, there is
syslog module that can store them in the system log (instead of, or in addition to the database log).
If you want to call your own logging/reporting tool, you can simply create a module and implement
hook_watchdog() to log them. Note that
watchdog() is called to log events that you probably don't want to log, such as users logging in, node CUD events, user registrations, etc. You can filter them down by inspecting the parameters passed for the hook implementation.