SitePoint Sponsor

User Tag List

Results 1 to 9 of 9
  1. #1
    SitePoint Guru phantom007's Avatar
    Join Date
    May 2008
    Posts
    737
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)

    Question Type Hinting and Custom Errors

    Hi All

    I was going though this post as I was encountering the same problem. The solution mentioned there works.

    But I have a question, Suppose I have defined ClassA in a different file with the following code:

    PHP Code:
    namespace ABC;

    class 
    ClassA {
      public function 
    method_a (ClassB $b) {}

    Now, my colleagues needs to use it, so they use the following code:

    PHP Code:
    use ABC;

    class 
    ClassWrong{}

    try{
      
    $a = new ABC\ClassA;
      
    $a->method_a(new ClassWrong);
    }
    catch(
    Exception $ex) {
      echo 
    "catched\n";

    and in order to raise the custom exception, they need to add the following codes as well

    PHP Code:

    function myErrorHandler($errno$errstr$errfile$errline) {
      if ( 
    E_RECOVERABLE_ERROR===$errno ) {
        echo 
    "'catched' catchable fatal error\n";
        throw new 
    ErrorException($errstr$errno0$errfile$errline);
        
    // return true;
      
    }
      return 
    false;
    }
    set_error_handler('myErrorHandler'); 
    So, I was wondering is there anyway I can add the myErrorHandler() and set_error_handler functions in the parent class so that my colleagues do have to add those code in their file?


    Thanks in advance for any inputs

  2. #2
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,129
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    I may be wrong here, as I'm not the most versed in how PHP handles exceptions, but why does ClassWrong need a try/catch?

    Typically you only use a try/catch when you want to catch a possible exception and handle it. Otherwise, you let it bubble up on its own. The reason being, try/catches are expensive operations. You are waiting to see if something fails, catch it before it goes through to the normal error handling, and then attempting to resolve it and usually there is a lot of work by the language to perform that (hence the expensive statement).

    Since there is a try/catch in ClassWrong, I assume there is additional processing that the class needs to do when the error occurs and thus they should ensure they are handling the error after their additional processing properly as well. I don't see why you'd want to put that responsibility on a class who does not need to handle this extenuating circumstance.

  3. #3
    SitePoint Guru phantom007's Avatar
    Join Date
    May 2008
    Posts
    737
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Sorry for creating the confusion. The try/catch is NOT a part of the WrongClass. WrongClass is just an empty class thats created so that we can use it for raising the exception. Let me reformat the code:

    PHP Code:
    class ClassWrong{
    // empty class
    }

    use 
    ABC;
    class 
    XYZ {

    public function 
    execute(){

    try{
      
    $a = new ABC\ClassA;
      
    $a->method_a(new ClassWrong);
    }
    catch(
    Exception $ex) {
      echo 
    "catched\n";
    }  

    }



  4. #4
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,268
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cancer10 View Post
    So, I was wondering is there anyway I can add the myErrorHandler() and set_error_handler functions in the parent class so that my colleagues do have to add those code in their file?
    Technically, yes, you could, probably as simply as copy-pasting the set_error_handler snippet into the ClassA file. But, you shouldn't do that. I suspect it shouldn't be done at the point that your colleagues are doing it either. This should be done at or near the highest/earliest point of the application, probably only for the purposes of logging the problem, possibly sending an automated email to your devs, and showing the user a more friendly "Something went wrong" message. Aside for those cases, this is the kind of error that you want to bubble up, because it's telling you about an error in your programming logic.
    "First make it work. Then make it better."

  5. #5
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,129
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cancer10 View Post
    Sorry for creating the confusion. The try/catch is NOT a part of the WrongClass. WrongClass is just an empty class thats created so that we can use it for raising the exception. Let me reformat the code:

    PHP Code:
    class ClassWrong{
    // empty class
    }

    use 
    ABC;
    class 
    XYZ {

    public function 
    execute(){

    try{
      
    $a = new ABC\ClassA;
      
    $a->method_a(new ClassWrong);
    }
    catch(
    Exception $ex) {
      echo 
    "catched\n";
    }  

    }


    I stand by my statement. Your try/catch doesn't give you anything in that usage, and you should just let the error bubble up. Unless you are going to perform an action when the exception occurs, you don't need a try/catch.

  6. #6
    SitePoint Guru phantom007's Avatar
    Join Date
    May 2008
    Posts
    737
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    Technically, yes, you could, probably as simply as copy-pasting the set_error_handler snippet into the ClassA file.
    Well thats the trickest part. I tried doing that but in vain. Remember the ClassA is NOT being included using the include() function but is refrenced with a namespace. Actually my colleague is trying to write a PHPUnit test cases for a class that was written by me (ClassA in this case). So he is arguing that the set_error_handler() function should be mentioned in ClassA itself because in real life when developers are using ClassA then the exception should raise automatically when they refrence a wrong class instance in method_a() param. And I think he has a valid point.

  7. #7
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,268
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cancer10 View Post
    Well thats the trickest part. I tried doing that but in vain. Remember the ClassA is NOT being included using the include() function but is refrenced with a namespace.
    If you mean that ClassA is being included with an autoloader, then that shouldn't cause an issue. Even autoloaders ultimately use include/require.

    Quote Originally Posted by cancer10 View Post
    Actually my colleague is trying to write a PHPUnit test cases for a class that was written by me (ClassA in this case). So he is arguing that the set_error_handler() function should be mentioned in ClassA itself because in real life when developers are using ClassA then the exception should raise automatically when they refrence a wrong class instance in method_a() param. And I think he has a valid point.
    It is a valid point. The counter valid point is that the error handler doesn't affect just ClassA. It will catch and throw all recoverable errors from anywhere in the whole application. It's global. And it should go somewhere in your code that makes it obvious that it's global. Placing it inside the ClassA file might give a false impression that it affects only ClassA.
    "First make it work. Then make it better."

  8. #8
    SitePoint Guru phantom007's Avatar
    Join Date
    May 2008
    Posts
    737
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    If you mean that ClassA is being included with an autoloader, then that shouldn't cause an issue. Even autoloaders ultimately use include/require.
    We are using Zend Framework 2 so I am not sure how does it work internally, all I know is it uses namespaces.



    Quote Originally Posted by Jeff Mott View Post
    It is a valid point. The counter valid point is that the error handler doesn't affect just ClassA. It will catch and throw all recoverable errors from anywhere in the whole application. It's global. And it should go somewhere in your code that makes it obvious that it's global. Placing it inside the ClassA file might give a false impression that it affects only ClassA.
    I got your point, will do that later but for now I need to figure out how to make it work by placing the error handler in ClassA


    <offtopic>
    Loved your siggy
    </offtopic>

  9. #9
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,268
    Mentioned
    18 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cancer10 View Post
    ...but for now I need to figure out how to make it work by placing the error handler in ClassA
    At this point, you'll probably have to post your real ClassA (whatever that might be), because putting the error handler in the ClassA file should work.

    Quote Originally Posted by cancer10 View Post
    <offtopic>
    Loved your siggy
    </offtopic>
    "First make it work. Then make it better."


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •