Enhanced exception handling for BeanExceptions in AnnotationBeanFactory

[dropdevcoding]

I recently ran into a problem concerning the exception handling while instanciating a bean.

If you write or use a class, which throws an exception during the constructor call, I get the following when trying to instanciate the bean by calling $beanFactory->get('myClass') for a CLI application:

PHP Fatal error:  Uncaught exception 'bitExpert\Disco\BeanException' with message 'Holy sh*t!' in /var/www/acme/vendor/bitexpert/disco/src/bitExpert/Disco/AnnotationBeanFactory.php:70
Stack trace:
#0 /var/www/acme/web/index.php(26): bitExpert\Disco\AnnotationBeanFactory->get('myClass')
#1 {main}
  thrown in /var/www/acme/vendor/bitexpert/disco/src/bitExpert/Disco/AnnotationBeanFactory.php on line 70

what hides any information about the original exception and makes it difficult to debug.

In my case the error message was "Make sure you are passing in the correct parameters" which also could be an error of my bean configuration as well (wrong reference inside a @parameter annotation).

If the original exception is passed as previous for the BeanException, we will see the correct stack trace (at least when using XDebug).

[shochdoerfer]

To discuss: Maybe we should pass the original exception to the BeanException and not just the exception message? Because now we loose the filename and line number where the original exception occurred. In some cases this could make the debugging quite complicated, I assume. What do you think?

[dropdevcoding]

I recently tested your suggestion and I'm struggling right now between having the exception and its trace as message by using:

throw new BeanException($e)

which gives a nice representation of the previous exception probably even without using XDebug

PHP Fatal error:  Uncaught exception 'bitExpert\Disco\BeanException' with message 'exception 'Exception' with message 'Holy sh*t' in /var/www/acme/src/Acme/MyClass.php:25
Stack trace:
#0 /var/www/acme/src/Acme/Config.php(205): Acme\MyClass->__construct(Array, Array)
#1 /tmp/acme/di/ProxyManagerGeneratedProxy__PM__AcmeConfigGenerated453471822132c786ea6e8ab9d9ab9b3a.php(363): Acme\Config->myClass(Array)
#2 [internal function]: ProxyManagerGeneratedProxy\__PM__\Acme\Config\Generated453471822132c786ea6e8ab9d9ab9b3a->myClass()
#3 /var/www/acme/vendor/bitexpert/disco/src/bitExpert/Disco/AnnotationBeanFactory.php(68): call_user_func(Array)
#4 /var/www/acme/web/index.php(18): bitExpert\Disco\AnnotationBeanFactory->get('myClass')
#5 {main}' in /var/www/acme/vendor/bitexpert/disco/src/bitExpert/Disco/AnnotationBeanFactory.php:76
Stack trace:
#0 /var/www/acme/web/index.php(18): bitExpert\Disco\AnnotationBeanFactory->get('myClass')
#1 {main}
 in /var/www/acme/vendor/bitexpert/disco/src/bitExpert/Disco/AnnotationBeanFactory.php on line 76

and

throw new BeanException($message, null, $e)

which is imho the technically correct approach but gives you only a nice trace if using XDebug:

PHP Fatal error:  Uncaught exception 'Exception' with message 'Holy sh*t' in /var/www/acme/src/Acme/MyClass.php:25
Stack trace:
#0 /var/www/acme/src/Acme/Config.php(205): Acme\MyClass->__construct(Array, Array)
#1 /tmp/acme/di/ProxyManagerGeneratedProxy__PM__AcmeConfigGenerated453471822132c786ea6e8ab9d9ab9b3a.php(363): Acme\Config->myClass(Array)
#2 [internal function]: ProxyManagerGeneratedProxy\__PM__\Acme\Config\Generated453471822132c786ea6e8ab9d9ab9b3a->myClass()
#3 /var/www/acme/vendor/bitexpert/disco/src/bitExpert/Disco/AnnotationBeanFactory.php(68): call_user_func(Array)
#4 /var/www/acme/web/index.php(18): bitExpert\Disco\AnnotationBeanFactory->get('myClass')
#5 {main}

Next exception 'bitExpert\Disco\BeanException' with message 'Exception occured while instanciating bean "myClass"' in /var/www/acme/vendor/bitexpert/disco/src/bitExpert/Disco/AnnotationBeanFactory.php:75
Stack trace:
#0 /var/www/acme/web/index.php(18): bitEx in /var/www/acme/vendor/bitexpert/disco/src/bitExpert/Disco/AnnotationBeanFactory.php on line 75

When using the first approach we would lose the possibility to traverse the exception stack via $e->getPrevious(), which may cause other problems when using logging libraries etc. and that is why I prefer the second approach.

[shochdoerfer]

Sounds good to me. Thanks. Can you make the needed change to the PR please?

[dropdevcoding]

The second approach has already been implemented in this pull request to achieve the goal described above.