The bin script handlers in TWiki::UI operate by writing a response to the HTTP request directly on STDOUT. They inherited this approach from the old bin scripts, but frankly it's a bit of a mess. The error handling especially is a bit "hit and miss", and very fragile. Anyone trying to add a handler, or understand what's there, has a challenge. It badly needs cleaning up.

Each script has pretty much the same set of possible responses available to it.

1. Fatal error
   • Installation error, such as read permissions failure or missing data
   • Compile error
   • Fatal error from spawned code
2. Non-fatal software error that prevents completion of the task
   • Write permissions failure
   • RCS error
   • Other non-fatal response from spawned code
3. User error (dirty redirect)
   • Locked topic
   • Access denied
   • Topic does not exist
   • Improper use of a script
4. Clean redirect - e.g. to view script
5. Clean page - generate the required HTML

The current approach requires detection of errors before any response is compiled. Otherwise there is a risk that a partially completed page content is overridden by a redirect and lost. This approach creates complex code, as checking is divorced from usage steps and unnatural things have to be done in odd sequences, and print statements appear with strange global variables controlling them.

Even printing a header dictates the content-type of the response, so we really want to know about all possible errors before anything is printed.

In general we want a single run of a script to report as many errors are possible, but still do as much as it can, so the simple approach of returning immediately after the first error is probably not a good idea.

Proposal

Adopt the following error handling strategy:

1. Fatal error
   • Use die.
   • Each bin script has identicl code fragment to handle eval{}if($@).
     • This reports the error to STDERR and warning.txt and writes a text/plain error message to STDOUT.
   • This would also trap compile errors
2. Non-fatal software error
   • Prepend an error message to the output page, and disable redirection
3. User error
   • Prepend and error message to the output page
   • Also request redirection to an error page
   • If redirection gets disabled (because of a non-fatal softwar error) then the output page will be printed

This object could also support late setting of the content type (useful e.g. for debugging) and changing the destination to a redirect. The only print will be in the script in 'bin', where it will print the output object.

-- CrawfordCurrie - 23 Aug 2004

I would also like to see an error return strategy for reporting of non-trivial errors at the function and module level.

For example, there are a number of places in Store that we need to be able to inform the calling script of the complex (implemetation dependant) details of an error in the store.

-- SvenDowideit - 23 Aug 2004

Most error handling is now done using exceptions, which is much clearer and more reliable (DEVELOP branch).

-- CrawfordCurrie - 13 Feb 2005