Resurrecting Error Handling Issues

Resurrecting Error Handling Issues

by Mike Churchward -
Number of replies: 9
Picture of Core developers Picture of Plugin developers Picture of Testers
I've come across what I think is a need for a function that displays important error messages to an admin-level user but not a regular user. This would be an error where the function can continue, but indicates an issue that should really be handled by the admin.

This was sort of discussed here (http://moodle.org/mod/forum/discuss.php?d=47774), but the 'print_error()' function really won't work in this case.

As an example, 'print_recent_activity' includes module library files. If that file doesn't exist (indicating that the module files may have been deleted even though the module may be still loaded in the module database), the function could continue for the user. But, the administrator should probably know about this so that the situation can be fixed.

Do we have a function now that would log an issue for an administrator? If not, should we?
Average of ratings: -
In reply to Mike Churchward

Re: Resurrecting Error Handling Issues

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I would hack the standard libraries, so that just after accesslib has been included (near the top of setup.php?), it does

if (has_capability('moodle/site:config', get_context(CONTEXT_SYSTEM)) {
$CFG->debug = E_ALL;
error_reporting($CFG->debug);
}

or something similar.
In reply to Tim Hunt

Re: Resurrecting Error Handling Issues

by Mike Churchward -
Picture of Core developers Picture of Plugin developers Picture of Testers
Hmmm. I was thinking of something more formal, built into Moodle, where these messages could be captured and/or displayed. Something like print_error, but that would be logged even if not displayed on the screen.
In reply to Mike Churchward

Re: Resurrecting Error Handling Issues

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
You can already configure Moodle like this. Look under admin > server > debugging. You can set it to whatever levels of warning you like, and then choose whether you want the errors on-screen, or in the PHP error log. At least, that is the case in Moodle 1.9.
In reply to Tim Hunt

Re: Resurrecting Error Handling Issues

by Mike Churchward -
Picture of Core developers Picture of Plugin developers Picture of Testers
Yes. And that dictates how errors generated by PHP get handled, correct?

What I'm looking for is a Moodle function that can be called from code and generate an error/informational message that can be seen by the administrator and not general users. Does that exist?
In reply to Mike Churchward

Re: Resurrecting Error Handling Issues

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Yeah if you call debugging() then those messages go to the PHP error log too...
In reply to Martin Dougiamas

Re: Resurrecting Error Handling Issues

by Mike Churchward -
Picture of Core developers Picture of Plugin developers Picture of Testers
I guess that would do it... I always looked at that as more of a tool for developers, but I guess we could educate the site admins to use that too.

And, just to clarify, I was thinking of a function that would provide information to an admin when something wasn't right with the site. These aren't bugs so much as they are issues that have been created by admin level functions. Such as the example I gave where a module's files have been removed but the module has not been deleted from the admin function.

I think 'debugging' could do it, but I'm not sure all admins would know to go and look at the site error logs.
In reply to Mike Churchward

Re: Resurrecting Error Handling Issues

by Richard Enison -
MC,

At least, of course, until someone creates a GUI that would enable the admin types to access the relevant info in the logs, and present it in a user-friendly format; and that would let them know that such info exists with no effort on their part; maybe even a count of items available, etc.

RLE
In reply to Richard Enison

Re: Resurrecting Error Handling Issues

by Martín Langhoff -
Just make a utility that reads the apache error logs.

Some web apps (such as Drupal) redirect the internal errors to a DB-based user friendly facility - but this causes huge problems when there is actually an error because you cannot use the web app to read the logs when the web app is broken. This is similar to the VoIP systems -- people are used to phones working in emergencies, such as power outages. VoIP phones are cute but if there's no power... you are toast.

So fancy displays within Moodle are good - but logging of errors should not be handled by PHP code, cause when things break, you need that logging to be independent of PHP code smile
In reply to Tim Hunt

Re: Resurrecting Error Handling Issues

by Martín Langhoff -

And for any serious development you really need to set the debugging messages to go only to the logs - not on-screen (which is actually "in the middle of your HTML/XML/JS/CSS"). I have it set everywhere to only log warnings and errors, and have an xterm tailing the error log (with tail -f /var/log/apache/error.log).

The 'display stuff in the html output' default of PHP is weird. Even if your html is 100% correctl, enable debugging and any warnigns will break your XHTML, your JS, and possibly CSS too.