The one issue I've had with this is if I set the parameter after dispatch() has already been called on the front controller – i.e., from a plugin. In such a case, by the time that routeStartup() has hit, pushing the parameters into the front controller will have no effect on the router or dispatcher. If this is what you are doing, you may need to push that setParam() into your bootstrap or index.php prior to calling dispatch().

$frontController->returnResponse(true);
$response = $frontController->dispatch();

/My own class for handling headers./
$response->sendResponse();

And let's try my code, set $frontController->setParam('useDefaultControllerAlways', false); and go to http://domain/non/existent > Invalid controller specified. Now $frontController>throwExceptions(false); -> Action "error" does not exist and was not trapped in __call(). W can read http://framework.zend.com/manual/en/zend.controller.exceptions.html "By default, the error handler plugin is registered and active...By passing a boolean true value to this method, you can tell the front controller that instead of aggregating exceptions in the response object or using the error handler plugin, you'd rather handle them yourself.". So as You can see everything is working as it should.

Now use default ZF code. $frontController->setParam('useDefaultControllerAlways', false); and go to http://domain/non/existent > index/index was loaded. Why? $frontController>throwExceptions(false); -> index/index . Nothing is working. You can also search google - there are several sites where people complain of such strange behavior.

That said, I think I know where the confusion lies: when an action is also provided via the URL. Let's look at the flow:

• invalid controller detected
• controller rewritten to IndexController
• action called on IndexController
• IndexController does not find action method, and invokes __call()
• __call() recognizes that an undefined action was called, and throws an exception
• the ErrorHandler plugin detects the exception and invokes the ErrorController

So, the useDefaultControllerAlways flag is doing exactly as it should. The problem is that there is an expectation that the action controller will fall back to a default action as well. And that's the real issue here.

I'm re-opening the issue and noting that when the default controller is selected in such a case that the default action as defined in the dispatcher should also be utilized.