This is a fix:

--- lib/TWiki/Plugins.pm-       2004-04-26 22:57:10.000000000 -0500
+++ lib/TWiki/Plugins.pm        2004-04-26 22:59:38.000000000 -0500
@@ -246,7 +246,13 @@

     foreach $theHandler ( @{$registeredHandlers{$handlerName}} ) {
         # apply handler on the remaining list of args
-        $status = &$theHandler;
+        eval {
+           $status = &$theHandler;
+        };
+        if($@) {
+           TWiki::writeWarning("Plugins: $theHandler ABORTED: $@");
+           return "ABORTED: $@";
+        }
         if( $onlyOnceHandlers{$handlerName} ) {
             if( $status ) {
                 return $status;

-- MartinCleaver - 27 Apr 2004

Questions:

1. What case did you experience that justifies this patch?
   • Calendar Plugin failed during preview - I haven't yet worked out why but I can't have the site crash -- MRJC
     • Possibly caused by a relative path in setlib.cfg? -- PTh
       • Nope - thanks for the suggestion but changing that made no difference. -- MRJC
2. What version of TWiki does that apply to? FYI, up to and including TWikiRelease01Feb2003 Plugins could fail silently. Errors are now redirected to STDERR, e.g. Plugin compile errors should be visible in the browser via CGI::Carp
   • TWikiAlphaRelease of about 2 weeks ago
     • There is no point showing users Plugin compile errors - I want to see them in a log -- MRJC
       • And possibly never detect. I prefer an e-mail from a user reporting an error -- PTh
         • I'd prefer to wire writeWarning through AppendTextToTopic into a system web and then get notified according to whatever schedule I set on the NotificationPlugin (or indeed, get immediate notified when NotificationPlugin is adapted to send instant messages) -- MRJC
3. What is the performance impact of changing a direct call to an eval? It might be expensive for the outsidePREHandler and insidePREHandler that are called in a tight loop/
   • I don't know. -- MRJC
     • These two handlers are the worst performance offenders. Could you provide benchmarks with/without the fix with a Plugin what uses those callbacks? -- PTh
4. Wouldn't it be better to skip just the one faulty Plugin? You break out of the Plugin callback chain on error.
   • Yes, certainly. -- MRJC
     • But I think this is what I wrote, no? (see below - this gets called with a given handlerName - theHandler is set to each row in this table: ) -- MRJC

Output of FAILEDPLUGINS

-- MartinCleaver - 27 Apr 2004

Application

sub applyHandlers
{
    my $handlerName = shift;
    my $theHandler;
    if( $TWiki::disableAllPlugins ) {
        return;
    }
    my $status;

    foreach $theHandler ( @{$registeredHandlers{$handlerName}} ) {
        # apply handler on the remaining list of args
        eval {
           $status = &$theHandler;
        };
        if($@) {
           TWiki::writeWarning("Plugins: $theHandler ABORTED: $@");
           return "ABORTED: $@";
        }
        if( $onlyOnceHandlers{$handlerName} ) {
            if( $status ) {
                return $status;
            }
        }
    }

    return undef;
}

I think we need a new TopicClassification: PatchBenchmarkingRequired

-- MartinCleaver - 16 May 2004