This is a fork of #522746: Drupal Exception Wrapper Class so that at least a basic version can get into D7.

In the current version of core, only uncaught exceptions can reasonably provide info about the location where it was thrown easily. For caught exceptions that should still be logged so the site admin knows about it, logging that info is a hassle because of the way the functions are organized (they are clearly not meant to be called that way).

Also, the info logged could use some improvement as well.

Summary of changes:

* Added watchdog_exception to bootstrap.inc
* Moved _drupal_decode_exception from common.inc to bootstrap.inc (is now needed in the same scope as watchdog for processing trace data)
* Moved the watchdog call out of _drupal_log_error and into the handlers because Exceptions and errors now log slightly differently and this was preventing code re-use.
* Renamed _drupal_log_error to _drupal_display_error because it no longer logs, but still formats the error info for display to the screen / simpletests / etc.
* Simplified the usage of _drupal_get_last_caller by giving it a default backtrace if one isn't provided (debug_backtrace).
* Comment-only changes to simpletest module.

Net Effect:

* Caught exceptions can easily be logged if desired
* Added context for where the exception was caught, rather than only where it was thrown.
* The watchdog_exception caller can optionally add more info. Currently used to clearly label uncaught exceptions as such, see example below for other possible usage.

Example:


try {
  throw new Exception(t('test !one !two',array('!one'=>'a','!two'=>'b')));
} catch (Exception $e) {
	// Optionally log the Exception, if the site admin should know it happened.
	// Or, to add debug info while you're developing.
  watchdog_exception($e); // Normally this is all you need to provide.
  // If you want to provide extra info to aide in debugging, use this format.
	watchdog_exception(
	  $e,
		'Encountered during render of block %block_id',
	  array('%block_id' => '5'),
	  WATCHDOG_WARNING,
	  l('Account','User')
	);

}
return 'All is Well';

CommentFileSizeAuthor
watchdog_exception.patch10.34 KBkwinters

Comments

kwinters’s picture

Status: Active » Needs review

CNR would help.

jrchamp’s picture

I like this concept. It more clearly separates the watchdog and _drupal_log_error mechanisms. Plus, it adds a useful utility function for exception handling.

chx’s picture

So tell me again what do we win by moving lots of code from common.inc to bootstrap.inc which loads on cached pages even...?

kwinters’s picture

Saying "lots of code" is an exaggeration, it's one moderate-size function that has been moved plus the new function.

Watchdog is in bootstrap, so watchdog_exception should be as well (changing that is a topic for another issue). Right now the code that pulls the file and line number out of the trace is in common.inc, and getting it in the right scope either means moving it to boostrap or require_once('includes/common.inc'), which is a possibility but I don't know if it will break anything or not.

Crell’s picture

Subscribing, as we're pondering if this could be useful for DB transactions to allow us to queue up watchdog messages to get committed after a transaction is rolled back.

klausi’s picture

Issue tags: -API clean-up

watchdog_exception.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +API clean-up

The last submitted patch, watchdog_exception.patch, failed testing.

kwinters’s picture

This should just need a re-roll against head for it to test out. I can do it if someone is willing to review soonish. Also, this may bump up against API change deadlines (even though it really just adds another logging function).

berdir’s picture

Ups, didn't know about this issue :)

http://api.drupal.org/api/function/watchdog_exception/7 was added as a solution to #711108: Richer exception reporting for watchdog(). Similiar but not the same as your patch. You might want to read the current code and re-roll your patch based on the current core code...

kwinters’s picture

Title: Watchdog Exception » Exception Handler Logging and Improvements

This is definitely worth keeping open. It has a bunch of improvements to the core error handler as well. If there is interest in it / someone willing to review it, I can reroll.

Crell’s picture

kwinters: Can you summarize what would be left in this issue now that watchdog_exception() is in? That will help us figure out if it's worth while.

kwinters’s picture

These are the changes that are still applicable:

* Separate the logging of errors / uncaught exceptions from their display, which simplifies some messy code paths and allows for the following item.
* Use watchdog exception in the uncaught exception handler for better results (and code reuse) -- previously the exception object was already out of scope when the log entry is created.
* Simplified the usage of _drupal_get_last_caller by giving it a default backtrace if one isn't provided (debug_backtrace).

Crell’s picture

Those all sound like good things to me, so I'm +1 on rerolling with those.

Crell’s picture

Status: Needs work » Closed (won't fix)

The code has changed enough in the last 5 years that I don't believe this is still relevant. Exceptions are handled COMPLETELY differently now.