Display Exception From CAction (Production Environment)

Part of my site breaks up its actions into separate CAction extended classes as explained here. Everything works fine on my local machine with YII_DEBUG set to true.

However, when I move to my production environment and turn debug off (and set display_errors=off in php.ini) my server falls into an unresolvable loop whenever it tries to throw an exception from within the action’s run() method. (The simple exception I am raising on purpose is caused by rendering a view file that does not exist.) If I trip the exact same exception from an action defined normally in the same controller (public function actionDoStuff()) it works fine.

My guess is that the exception being tripped inside the extended action is causing another exception while trying to resolve it, which then causes another exception, etc…

Do I need to define a separate error handler for my extended action class? The error action of the controller this extended action has been attached to is not being triggered. Does anyone have an idea how I can go about figuring out how Yii is attempting to handle the errors caused inside the CAction so that I can trace down where the infinite loop is taking place?

I don’t see how to delete my original post, so I will just reply instead… who knows, maybe somebody else will run into this same problem someday.

It turns out that the problem was caused by the Action requiring SSL whereas the default error handler (site/error) did not. I control SSL for my actions using a controller filter, and so when an exception was thrown inside an action that requires SSL I was being trapped inside a loop. The action required SSL be turned on, and then when loaded it tripped an exception which required site/error to be used. site/error requires non-ssl so the filter turned https off and then (presumably) reloaded the page as non-https. The error handler does not actually change the route being processed (the browser still shows site/action instead of changing to site/error) so when the filter reloaded the page it used the original site/action route, which the filter then said “hey that’s supposed to be in SSL!”, turned on SSL and then tripped the exception. And on and on it goes.

The solution was to add a check within my HTTP(S) filters to ignore SSL rules when it detects an action of ‘error’.

Weird and annoying to track down… but at least I learned something.