Error handling

[TheArgh]

I have started writing a plugin, and was wondering how any errors occurring in the plugin should be handled. Ideally, any errors occurring in the plugin should not bubble up to the user nor halt the script. But how do you communicate the error 1) to the user 2) to the developer? Is there a standard for this in Serendipity?

For example, my plugin makes a HTTP request using HTTP_Request. If this fails, the plugin can't render its content properly. I currently display a user-safe textual message like "No entries available" and write an error log with a corresponding error code and any useful additional info for debugging purposes.

I could not really find any hints regarding this otherwise...?

[garvinhicking]

Hi!

Actually, there is very little standard upon error handling. Like any good PHP application, most plugins just swallow it or die ungraciously...

Anyways, wanting to do that is a good thing. Here's some suggestions:

1. You can make your plugin create a logfile or log errors to a database. Then you can use the backend_frontpage_display event hook to display those errors in the overview panel.

2. Or you can emit problems inside the plugin configuration screen. There use the "example" method that is called from your plugin to indicate any plugin code.

3. You could also send a mail to the user telling him errors.

4. Or, what would be terribly exiting is to use the external_plugin hook to create a RSS feed that holds error reports!

Then again, I'm also very open to any suggestions!

Best regards,
Garvin

[TheArgh]

Hi Garvin,

Thanks for the info! Items 1, 2 and 3 seem to be good solutions that one can choose depending on the type of error. I think plugin configuration issues can be checked via the example() method while functional errors can be mailed/displayed...

Otherwise, I don't like swallowing errors ungraciously - they have a tendency to get stuck in my throat

Regarding #4, that would indeed be nice - especially since this would require unifying error handling somewhat and adding an API for that Ideally, the user should be able to choose in the serendipity configuration how he would like to be notified of errors: via an RSS feed, emails, logs... etc.

Yay! Ideas... isn't that what makes programming fun?

[garvinhicking]

Hi!

Great - actually 1.0 should also have a validate() method that can check configuration errors. Any errors found then should be displayed natively in the interface...

Otherwise, I don't like swallowing errors ungraciously - they have a tendency to get stuck in my throat

Sssh. If you don't think about that and just close your eyes, all is fine! That way the ostrich seems to survive pretty well in nature ))

Regarding #4, that would indeed be nice - especially since this would require unifying error handling somewhat and adding an API for that Ideally, the user should be able to choose in the serendipity configuration how he would like to be notified of errors: via an RSS feed, emails, logs... etc.

You are right, this really sounds pretty nifty. Actually it could be made with a plugin and a new "logger_error" hook. Plugins could call this, and could implement their own logger_error event handles, if they care. Plus, a super-plugin could handle all logger_error events (on top of local logging) to offer such RSSfeeds/mails/logfiles.

Of course current code would also need to be swamped with such hooks, which isn't but but just a lot of grunt work.

Sounds exciting, actually.

Best regards,
Garvin

[TheArgh]

Great - actually 1.0 should also have a validate() method that can check configuration errors. Any errors found then should be displayed natively in the interface...

That's good news! I'll have a look at the beta then and see if I can use that in my plugin

You are right, this really sounds pretty nifty. Actually it could be made with a plugin and a new "logger_error" hook. Plugins could call this, and could implement their own logger_error event handles, if they care. Plus, a super-plugin could handle all logger_error events (on top of local logging) to offer such RSSfeeds/mails/logfiles.

That would be perfect, as it would be easy to use and unify the error handling at the same time, which can never be a bad thing! And you don't have to worry about the way the errors are handled in your plugin...

Of course current code would also need to be swamped with such hooks, which isn't but but just a lot of grunt work.

I would suggest a plugin-specific helper method that creates the hook for you so you only have to care about providing the error details like

Code: Select all

$this->logError( 4, 'Aaargh! An error is stuck in my throat!' );

... Even developers like a little comfort now and then

[garvinhicking]

That all sounds good! Now the final question, who's going to volunteer?

Error Handling and Documentation is for nerds only ) <gd&r>

Regards,
Garvin