CODEWITHSUNDEEP
phpexceptione-notices
user2066805
user2066805

Reputation:

When an exception is thrown and bubble up where a solution is found, how can we send the control back to where the exception was thrown?

For concreteness, I present some code, in which what I want, I know, is not possible. I am looking for another way to get the same. 

<?php
  error_reporting(E_ALL | E_STRICT); 

  function exception_error_handler($errno, $errstr, $errfile, $errline ) {
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
    // When $errno is a notice, we would like a way for the execution to continue here. Since it is only a notice, eventually it could go back to where the notice was triggered. 
  }

  set_error_handler("exception_error_handler");

  Class TopLevelManagement {
    private $genericInfo = "Very important to add in notices"; 

    function highleveljob() {
      try{
        // In practice, the following statements could occur below in the execution tree, after a few other function calls. 
        $specific = new SpecificAndEncapsulated();
        $specific->specificjob();
      }
      catch (ErrorException $e) {
        $message = $e->getMessage() . $this->genericInfo; 
        mail($admin_email, "Consider the generic info and recover from this situation", $message); 
        // Here we would like the execution to continue where the exception was thrown. In the real world, this would be like "thank you error handler for SpecificAndEncapsulated::specificjob, we have taken care of the issue with the help of our larger perspective.". 
      }   
    } 
  }

  Class SpecificAndEncapsulated {

    function specificjob() {
      // Some processing
      if($unexpected == true) trigger_error('Here is how little I know, as I should', E_USER_NOTICE);
      // Continue as expected after a notice.
    }
  }
?>

Of course, one solution is to pass $genericInfo as a parameter or as a global variable to SpecificAndEncapsulated::justdomyjob and let the error_handler take care of the issue without bubbling up any exception. However, this solution is not natural. There are other ways to systematically pass the variable $genericInfo to SpecificAndEncapsulated, but the issue will be the same. There should be no need to systematically pass the $genericInfo value, because it is not something that should concern SpecificAndEncapsulated, not even when an exception occurs, even less systematically at every call. A communication back to the issuer of the exception saying "thanks, now continue", after a notice has been managed at an higher level, is natural. Is there a support for this type of E_NOTICE or E_USER_NOTICE management?

Upvotes: 0

Views: 646

Answers (2)

Yaco Zaragoza
Yaco Zaragoza

Reputation: 437

PHP 5 has an exception model similar to that of other programming languages. An exception can be thrown, and caught ("catched") within PHP. Code may be surrounded in a try block, to facilitate the catching of potential exceptions. Each try must have at least one corresponding catch block. Multiple catch blocks can be used to catch different classes of exceptions. Normal execution (when no exception is thrown within the try block, or when a catch matching the thrown exception's class is not present) will continue after that last catch block defined in sequence. Exceptions can be thrown (or re-thrown) within a catch block.

When an exception is thrown, code following the statement will not be executed, and PHP will attempt to find the first matching catch block. If an exception is not caught, a PHP Fatal Error will be issued with an "Uncaught Exception ..." message, unless a handler has been defined with set_exception_handler().

In PHP 5.5 and later, a finally block may also be specified after the catch blocks. Code within the finally block will always be executed after the try and catch blocks, regardless of whether an exception has been thrown, and before normal execution resumes.

The thrown object must be an instance of the Exception class or a subclass of Exception. Trying to throw an object that is not will result in a PHP Fatal Error.

Upvotes: 0

Leonid Shevtsov
Leonid Shevtsov

Reputation: 14179

Exceptions, by design, are errors after which normal execution cannot continue.

In the real world, it would go like this: a police officer (third party) calls a trucking company dispatcher (the top-level code) and says, "one of your trucks exploded in a ball of fire and the driver is in the hospital" (the job), and the dispatcher says "Noted. I expect the payload to arrive on schedule."

You have to catch exceptions inside the job if you want to continue the job. One viable approach is to pass an error handler function or a delegate object into the job.

Upvotes: 0

Related Questions