When exceptions are thrown in custom helpers, they're caught in https://github.com/devtheorem/php-handlebars/blob/v0.9.9/src/Runtime.php#L443 and re-thrown as new Exception, losing information about the original (= caught) exception. Could we pass the caught exception as $previous to the re-thrown exception to somehow maintain this information?
Background: We use the library in TYPO3 CMS where we use custom helpers for a complex form rendering. In some circumstances, a form finisher throws an exception that must be passed through the entire middleware stack in order to propagate a shipped response. This information gets lost as soon as Runtime::exch re-throws the caught exception. We aim for such a solution in our library to re-throw the original exception: CPS-IT/handlebars@a9c2c76
Would you accept such an improvement for 0.9.x versions? I can see that you were already working a lot in this area and the described behavior might no longer be relevant with the recent modernizations. Since we already use the library in the 0.9.x versions on production, it would be nice to have this "fix" in place.
When exceptions are thrown in custom helpers, they're caught in https://github.com/devtheorem/php-handlebars/blob/v0.9.9/src/Runtime.php#L443 and re-thrown as new Exception, losing information about the original (= caught) exception. Could we pass the caught exception as
$previousto the re-thrown exception to somehow maintain this information?Background: We use the library in TYPO3 CMS where we use custom helpers for a complex form rendering. In some circumstances, a form finisher throws an exception that must be passed through the entire middleware stack in order to propagate a shipped response. This information gets lost as soon as
Runtime::exchre-throws the caught exception. We aim for such a solution in our library to re-throw the original exception: CPS-IT/handlebars@a9c2c76Would you accept such an improvement for 0.9.x versions? I can see that you were already working a lot in this area and the described behavior might no longer be relevant with the recent modernizations. Since we already use the library in the 0.9.x versions on production, it would be nice to have this "fix" in place.