>Exceptions should generally be reserved for exceptional behavior (like a
>database not being present, or file cannot be accessed altered.)
>Auth/Acl type stuff should be returning booleans when asked questions
>like 'is there a user' or 'does he have access'. In this case, you'd
>want to (during preDispatch()), alter the request object to direct them
>to the proper place, for example some kinda of NotAutorizedController.
I actually noticed this behaviour because memcached server used for session
storage
was inaccessible, that's pretty exceptional behaviour. Although it doesn't
really matter
why the exception is thrown, because the effect is always the same.
I have to assume the code may fail, even if I don't explicitly throw
anything.
>If throwExceptions() is false, then you should be able to get all
>exceptions throw during the dispatch loop inside your errorHandler /
>ErrorController, and you can further do more "Exceptional logic" there.
>-ralph
I can't really see any explanation or solution here, maybe I don't
understand your point.
My current plugin looks a bit like this:
public function dispatchLoopStartup(Zend_Controller_Request_Abstract
$request)
{
if (! Zend_Auth::getInstance()->hasIdentity()) {
//redirect to login page
}
//get acl, check access to requested module/controller etc.
throw new Exception('ups, something unexpected happened, database
down, whatever');
//redirect to not authorized page based on acl
}
The result is an error page (from error controller) but the requested action
still gets executed regardless of the exception which could happen before
I had a chance to redirect user to another page.
If I change the hook to preDispatch() it doesn't even get to the error page,
it's thrown from Zend_Controller_Front->dispatch() while the action is still
executed.
My current solution is to wrap all logic into try{} block and in catch{} do:
$request->setControllerName('error')->setActionName('error')->setDispatched(false);
This bypasses whatever action was requested and forwards user directly to
the error controller.
This issue made me question the way I wrote my auth plugin, but I've seen it
done
pretty much the same way by others. How would you do it?
Is there some recommended sample auth plugin anywhere that would be
unaffected by this issue?
Thanks
Karol
--
View this message in context:
http://www.nabble.com/Handling-exceptions-inside-front-controller-plugins-tp23480288p23639787.html
Sent from the Zend Framework mailing list archive at Nabble.com.
