Error Handling [was: Cron Improvements and Error Logging]

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Error Handling [was: Cron Improvements and Error Logging]

Sam Angove
On 3/9/06, Robert Deaton <[hidden email]> wrote:
>
> Error logging
>         Make the formal $wpdb->log table schema, which should be a table
> suitable enough for generic logging [...]
>         This whole thing is API'd out for custom log types and messages that
> plugins can display in the viewer.

Misc thoughts:

* If it's all "API'd out", Isn't it the error *handler* part that's
needed in the core, then, rather than the logger? Logging can be just
one of multiple possible actions when an error occurs, along with
emailing/paging the admin, displaying a message, redirecting to
another page...

* What about a pluggable error handler loaded like the object cache?

* I'm concerned about reliance on a DB table because one of the errors
I'm most interested in acting on is a failure to connect to the
database.

* It's hard to take action on specific errors unless there's some kind
of error code system, and error codes are a pain to remember. Is it
better to have a code for every different message -- in which case
there'll be a *lot* -- or just a few, like a general
"NOT_GOOD_ENOUGH_HA_HA" kind of thing sent with all of the permission
denied messages, "CANT_READ_COMMENT_INSTRUCTIONS" for the comment
posting errors, etc.?
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Error Handling [was: Cron Improvements and Error Logging]

Robert Deaton
On 3/9/06, Sam Angove <[hidden email]> wrote:
> * If it's all "API'd out", Isn't it the error *handler* part that's
> needed in the core, then, rather than the logger? Logging can be just
> one of multiple possible actions when an error occurs, along with
> emailing/paging the admin, displaying a message, redirecting to
> another page...

And thus the API'd out, if you want to send e-mails, an early loaded
plugin could do so for most userspace events. A hook inside the error
handler could allow custom code to be run. However, logging is the
reason for having an error handler, and a generic logger has, imho,
been something we've needed for plugin developers for a while.

> * What about a pluggable error handler loaded like the object cache?

More editing files, pain in the butt, a user shouldn't have to go
through the hassle.

> * I'm concerned about reliance on a DB table because one of the errors
> I'm most interested in acting on is a failure to connect to the
> database.

If you can't connect to your database, you have bigger problems.
Besides, how would WP know your e-mail address on how to contact you
and all if you can't connect to the database to begin with?

> * It's hard to take action on specific errors unless there's some kind
> of error code system, and error codes are a pain to remember. Is it
> better to have a code for every different message -- in which case
> there'll be a *lot* -- or just a few, like a general
> "NOT_GOOD_ENOUGH_HA_HA" kind of thing sent with all of the permission
> denied messages, "CANT_READ_COMMENT_INSTRUCTIONS" for the comment
> posting errors, etc.?

Now you're assuming everything is going to trigger an error, and that
all things will have error codes. The database schema allows for you
to not ever really have to remember some set of error codes, you just
write in the error with the message you want to display and that's
that.

And did you really have to split this off into a seperate thread? The
whole point of the original was to get feedback on this.

--
--Robert Deaton
http://somethingunpredictable.com

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Error Handling [was: Cron Improvements and Error Logging]

Sam Angove
On 3/9/06, Robert Deaton <[hidden email]> wrote:
>
>  However, logging is the
> reason for having an error handler, and a generic logger has, imho,
> been something we've needed for plugin developers for a while.

It's just two ways of looking at the same thing -- binding actions to
events -- except that I think the handler part is more important than
the log-action part. This is mostly because I care less about logging
most events than (for example) giving users a pretty custom error page
to look at, displaying status messages in the admin interface etc.

> If you can't connect to your database, you have bigger problems.
> Besides, how would WP know your e-mail address on how to contact you
> and all if you can't connect to the database to begin with?

That's the point! The handler can solve my bigger problems. It could
alert me to the difficulties. It could redirect visitors to a static
version of the site. It could be linked to a script that tries to
restart mysqld. At the very least it could be logged!

That's one of the reasons why I suggested a pluggable handler a la the
object cache. It gives extreme flexibility to people who don't care
about having to edit an extra file.

There's also no reason that the default handler couldn't be
user-friendly and use $wpdb when it becomes available:

   if (!empty($wpdb) && is_a($wpdb, 'wpdb')) // ...etc


> Now you're assuming everything is going to trigger an error, and that
> all things will have error codes. The database schema allows for you
> to not ever really have to remember some set of error codes, you just
> write in the error with the message you want to display and that's
> that.

Status code, then. Forget the error part. If you want to bind an event
to some specific action -- with do_action() in a plugin, for example
-- you need a code or some other kind of identifier. (Unless you're
just checking for a specific message string, and please let's not go
there...)


> And did you really have to split this off into a seperate thread? The
> whole point of the original was to get feedback on this.

Yes, because I didn't want to talk about cron. :P
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers