You are here: Foswiki>Tasks Web>Item13027 (08 Dec 2016, GeorgeClark)Edit Attach

Item13027: Regex error results in "Unspecified error" failure in Foswiki::UI

Priority: Urgent
Current State: Closed
Released In: 2.0.0
Target Release: major
Applies To: Engine
Component: FoswikiUI, SEARCH
Branches: master
Reported By: GeorgeClark
Waiting For:
Last Change By: GeorgeClark
A typo in a regex search results in a Foswiki::Infix::Error which is not properly caught. It results in a failure in without any diagnostics reported to either the browser or the logs. So there are two issues here., the "otherwise" clause which simply reports "Unexpected error" to the browser probably ought to die, or log some sort of diagnostics rather than hiding the issue.

Syntax errors in regular expressions in search should be caught and properly reported to the interface rather than resulting in an unexpected error in

I added a "die" call to get some meaningful information:

$VAR1 = \bless( {
                   '-file' => 'dummy',
                   '-text' => 'Bad regular expression \'.*.*)\'',
                   '-line' => 'dummy',
                   '-package' => 'Error'
                 }, 'Foswiki::Infix::Error' );
 at /usr/lib/perl5/vendor_perl/5.16.3/CGI/ line 378.
   CGI::Carp::realdie('$VAR1 = \bless( {\x{a}                   \'-file\' => \'dummy\',\x{a}...') called at /usr/lib/perl5/vendor_perl/5.16.3/CGI/ line 467
   CGI::Carp::die('$VAR1 = \bless( {\x{a}                   \'-file\' => \'dummy\',\x{a}...') called at /var/www/foswiki/distro/core/lib/Foswiki/ line 473
   Foswiki::UI::__ANON__('Foswiki::Infix::Error=HASH(0x8eb2f98)', 'SCALAR(0x818b138)') called at /usr/lib/perl5/vendor_perl/5.16.3/ line 378
   eval {...} called at /usr/lib/perl5/vendor_perl/5.16.3/ line 368
   Error::subs::run_clauses('HASH(0x8631f10)', 'Foswiki::Infix::Error=HASH(0x8eb2f98)', undef, 'ARRAY(0x818af08)') called at /usr/lib/perl5/vendor_perl/5.16.3/ line 430
   Error::subs::try('CODE(0x804eca8)', 'HASH(0x8631f10)') called at /var/www/foswiki/distro/core/lib/Foswiki/ line 475
   Foswiki::UI::_execute('Foswiki::Request=HASH(0x85bcc00)', 'CODE(0x805c910)', 'view', 1) called at /var/www/foswiki/distro/core/lib/Foswiki/ line 304
   Foswiki::UI::handleRequest('Foswiki::Request=HASH(0x85bcc00)') called at /var/www/foswiki/distro/core/lib/Foswiki/Engine/ line 91
   Foswiki::Engine::CGI::run('Foswiki::Engine::CGI=HASH(0x82a39d0)') called at view line 29.

-- GeorgeClark - 14 Sep 2014

The regex had a typo in the quotes:
lc(name)=~lc('.*%<nop>URLPARAM{\"match\" default=\"no default\"}%.*)'" 

This also fails on 1.1.9. See:

-- GeorgeClark - 14 Sep 2014

There are actually two problems; first, SEARCH doesn't trap errors cleanly. Second, traps Error::Simple but not the base class, Error. Since Foswiki::Infix::Error inherits off Error and not Error::Simple, misses it. All the Foswiki internal error classes inherit directly off Error, so trapping Error::Simple will in fact catch everything that is not a Foswiki error - a bit counter-intuitive.

There's actually a wider problem here. Most try..catch clauses catch Error::Simple, which is effective only for catching Foswiki-specific exceptions, such as OopsException, which are explicitly derived from Error::Simple. Most errors - and all internal Foswiki error classes - derive off Error, so those clauses should be using catch Error with

There is virtually no functionality difference between Error and Error::Simple, so a simple replacement of all catch Error::Simple with should be fine, so long as we are aware that some places may actually want to differentiate Foswiki exceptions from errors.

-- CrawfordCurrie - 31 Oct 2014


ItemTemplate edit

Summary Regex error results in "Unspecified error" failure in Foswiki::UI
ReportedBy GeorgeClark
Codebase 1.1.9, trunk
SVN Range
AppliesTo Engine
Component FoswikiUI, SEARCH
Priority Urgent
CurrentState Closed
Checkins distro:96110fcaab02 distro:74b3a0706fa2
TargetRelease major
ReleasedIn 2.0.0
CheckinsOnBranches master
masterCheckins distro:96110fcaab02 distro:74b3a0706fa2
Topic revision: r6 - 08 Dec 2016, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy