Critical error

From CunningPlans

A Critical Error is an error that indicates a severe problem with the program itself or the environment -- missing libraries, database server unavailable, etc. Every time a critical error occurs, the site admin is notified by email; it should thus be generated only in the gravest of situations.

A Critical Error should never be the result of something a user has done, such as sending a bad command name to a handler, filling out a form improperly, or trying to access a module without authorisation. Critical errors indicate that a Module or Site is badly broken and unusable by anyone.

Critical errors and fatal errors are not the same thing. An error may be fatal but not critical (user did something stupid, must be prompted to try again) or (less commonly) critical but not fatal (resource unavailable, must notify admin, but can go on without it).

[edit] Notification

A critical error generates email to the admin identified by the errornotify directive in the relevant module's Module section.

If the error occurs outside a module (such as in application startup), or the Module definition has no errornotify defined, the message is sent to the site-admin-email address in the Baldrick section.

If both of these configuration directives are absent then email notification is disabled.

[edit] Programming Critical Errors

Critical errors may be issued by any class inheriting Baldrick::Turnip. It is best to have the Handler issue the error, when possible, as it has ready access to the Module definition where errornotify may be found.

To issue a critical error, pass the "critical" flag to abort() or setError().

   if ($majorCrisis)
   {
       $self->abort("Socks - run out again!", critical => 1);
   }