text: 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:
  namespace ABC;
  class ClassA {
  public function method_a (ClassB $b) {}
  }
  Now, my colleagues needs to use it, so they use the following code:
  use ABC;
  class ClassWrong{}
  try{
  $a = new ABC\\ClassA;
  $a->method_a(new ClassWrong);
  }
  catch(Exception $ex) {
  echo "catched\
  ";
  }
  and in order to raise the custom exception, they need to add the following codes as well
  function myErrorHandler($errno, $errstr, $errfile, $errline) {
  if ( E_RECOVERABLE_ERROR===$errno ) {
  echo "'catched' catchable fatal error\
  ";
  throw new ErrorException($errstr, $errno, 0, $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
  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.
  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:
  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\
  ";
  }
  }
  }
  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.
  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.
  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.
  If you mean that ClassA is being included with an autoloader, then that shouldn't cause an issue. Even autoloaders ultimately use include/require.
  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.
  We are using Zend Framework 2 so I am not sure how does it work internally, all I know is it uses namespaces.
  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>
  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.
  This topic is now closed. New replies are no longer allowed.