Item852: Need a mechanism for error reporting

In a discussion in Tasks.Item727, Sven noted that there's a general problem that we don't have a good mechanism to report user errors from macros, plugins & the core.

We can write to the warning, error and debug log files, but those are accessible only to the the website administrator - not the topic author who creates them.

Sven noted that this is a hard problem.

I observed that there is a not-so-hard approach. Opening this item so that the idea doesn't get lost. I think the basic idea is sound, though there is room for some improvement...

Agree it's a general problem. Maybe not too hard.

Here's a possible approach:

• Reserve a topic in each web - say 'WebErrors'.
• Errors are written to this topic in a standard format:
  • #ErrorNumber<seq>
  • ---++ date-timestamp: Web.Topic:Rev: Component: Error: 1-line-summary
  • any error detail lines (traceback, parameters, etc)
  • date-timestamp: Error-end
    • This is a delimiter so anything can be logged
  • Component is core, plugin name, etc; Error is severity
• Standard error (possible warn, debug) routines that handle locking, sequence, format
  • Special cases:
    • always lock topic with error, then WebErrors to prevent deadlock
    • Errors on the WebErrors topic
    • Hard limit on topic size to prevent runaway errors/denial of service. Configurable - perhaps 10_000 lines to start?
  • Foswiki::userError("Summary", <<"Detail", {web=>, topic=>, rev=>, component=>}); hash params default to current topic, caller
• Error routine inserts [[WebErrors#ErrorNumber<seq>][ %RED%Error in <Component>%ENDCOLOR% ]] in topic with problem
  • Just after macro that causes problem, or foot of page if we can't do any better or aren't sure about nested macro calls
  • Provides link to data while maximizing chance that page is still useful
  • Do not update topic if no CHANGE access for viewer, or same Component has an error marker on page at this point.
• For bonus points, put a checkbox 'remove this error' on each heading under WebErrors & a 'submit' at bottom - makes it easy to remove when fixed
• Cron script (like statistics) to prune 'old' errors
• Note that an admin can subscribe to WebErrors with MailerContrib, or a maintainer/developer can put a SEARCH on his home page that looks for errors on a component or topic that he supports.

---

Here's another approach. Record the user who was logged in when the message was generated. Support searching of the logs, filtered on that user (or unfiltered for admins). Pipe the results through the existing mechanisms used for result presentation e.g. %SEARCH{"view" type="log" user="KarlMarx" since="2009-03-01"}%

Confirmed and regraded from Normal to Enhancement.

-- CrawfordCurrie - 08 Mar 2009