Development

#4741 (sfStopExceptions thrown in 404 actions are not caught)

You must first sign up to be able to contribute.

Ticket #4741 (reopened defect)

Opened 2 years ago

Last modified 1 year ago

sfStopExceptions thrown in 404 actions are not caught

Reported by: Sapheriel Assigned to: fabien
Priority: minor Milestone:
Component: controller Version: 1.2.8
Keywords: 404 sfStopException Cc:
Qualification: Unreviewed

Description

When using a custom 404 module/action, calling sfController::forward() or sfController::redirect() or any other part of symfony that results in an sfStopException being thrown, this exception will not be caught and thus result in a fatal error. The same is true for all other exceptions as well, but I'm highlighting sfStopExceptions because they are part of symfony's normal operation and it can be reasonably expected they be caught.

Analysis:

The forward to the 404 action happens inside the printStackTrace() method of the sfError404Exception that is throw and immediately caught in sfFrontWebController::dispatch(). There are no try-catch blocks around either the forward() call nor the printStackTrace call to catch exceptions that are throw as part of symfony's normal operation, or any exceptions for that matter.

Stack trace:

PHP Fatal error:  Uncaught exception 'sfStopException' in /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php:294
Stack trace:
#0 /var/www/promotions/current/apps/frontend/modules/error/actions/actions.class.php(19): sfAction->redirect('http://...', 404)
#1 /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php(462): errorActions->executeError404(Object(sfWebRequest))
#2 /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php(1109): sfActions->execute(Object(sfWebRequest))
#3 /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php(1104): sfExecutionFilter->executeAction(Object(errorActions))
#4 /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php(1093): sfExecutionFilter->handleAction(Object(sfFilterChain), Object(errorActions))
#5 /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php(1189): sfExecutionFilter->execute(Object(sfFilterChain))
#6 /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php(1051): sfFilterChain->execute()
#7 /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php(1189): sfCommonFilter->execute(Object(sfFilterChain))
#8 /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php(1152): sfFilterChain->execute()
#9 /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php(1189): sfRenderingFilter->execute(Object(sfFilterChain))
#10 /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php(734): sfFilterChain->execute()
#11 /var/www/promotions/current/lib/symfony/exception/sfError404Exception.class.php(49): sfController->forward('error', 'error404')
#12 /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php(2530): sfError404Exception->printStackTrace()
#13 /var/www/promotions/current/lib/symfony/util/sfContext.class.php(164): sfFrontWebController->dispatch()
#14 /var/www/promotions/current/web/index.php(9): sfContext->dispatch()
#15 {main}
  thrown in /var/www/promotions/current/cache/frontend/prod/config/config_core_compile.yml.php on line 294

Possible solutions:

One way to solve this problem would be to move the forward out of the printStackTrace() method since that strikes me as a weird place to put it in the first place. The other solution would be to place another try-catch block around either the forward or the printStackTrace() call to ensure that normal symfony behavior can occur without causing a fatal error.

Change History

07/01/09 12:48:13 changed by nicolas

  • status changed from new to closed.
  • resolution set to fixed.

(In [19779]) [1.1, 1.2, 1.3] added test to ensure embedded form fields id integrity (closes #4741)

07/01/09 12:49:37 changed by nicolas

(In [19780]) [1.2, 1.3] added test to ensure embedded form fields id integrity (closes #4741)

07/01/09 17:48:40 changed by nicolas

  • status changed from closed to reopened.
  • resolution deleted.

Hmm, sorry, wrong ticket closed.

07/06/09 16:22:35 changed by nicolas

  • status changed from reopened to closed.
  • resolution set to invalid.

This bug is no more, at least using latest r19919

08/02/09 15:05:03 changed by svewap

  • keywords set to 404 sfStopException.
  • status changed from closed to reopened.
  • version changed from 1.1.4 to 1.2.8.
  • resolution deleted.
  • milestone changed from 1.1.8 to 1.2.9.

It's still the fact that sfStopExcpetions which are thrown by redirects are not caught and produces entries in the php error log. rev 20691

09/14/09 00:05:46 changed by FabianLange

  • milestone deleted.

The Sensio Labs Network

Since 1998, Sensio Labs has been promoting the Open-Source software movement by providing quality web application development, training, consulting.
Sensio Labs also supports several large Open-Source projects.