On 6/23/2011 11:04 PM, Gary Mort wrote:
Exceptions can do most of the things user errors are used for, but one
thing they cannot do is continue executing from the point of the
exception being thrown. Once thrown, the block of code being executed
is aborted and the path of coding goes to the exception handler
instead. This could be used to generate an error message of some sort,
log a problem, etc.
Right. Throwing an exception means that you DON'T want to continue
executing at that point,
or otherwise you wouldn't be throwing an exception. It's definitely not
taking on the role of displaying
error messages.
As an example, consider a web page where we have a common header, a
common footer, and then the main section of the web page. For a
particular url, the data being displayed in the main section is
restricted to authorized individuals.
That's how people wrote PHP 10 years ago. In a modern design, the
user would visit a PHP page
which implements a "controller"; this controller inspects the rest of
the URL, decides which "view" to run
(which corresponds to the "main section of the web page"), runs the
view, stuffs the output into an output buffer,
and then runs the template, into which the text from the main section
is inserted.
In this case you can put the whole controller in a try-catch block
or you can put the view or the template in a
try-catch block.
If your application is more interactive (processes forms) it makes
sense to have an "action" that processes each form;
after the action runs it decides which view to display -- if there's an
error it can go back to the original view with error
messages added... It can also display a different form depending on
what you inputted. For instance, if you've got
a long application form broken up into 10 pages, you might be able to
skip from page 3 to page 7 because you've
got enough information to know the user doesn't need to fill those pages
out.
Exception handling: The code needs to be much more object oriented. For
the main body of code, you might have an object where you call a
generate header, generate content, and generate footer method. In the
generate content method, you would have to have a try block around the
authorization check and content generation, and if authorization fails
throw an exception. You would also need to catch the exception and in
the exception handling generate the error message to display for the user.
Using a modern architecture it's your choice for how
object-oriented you want to be. I wrote a microframework
that was 79 lines of PHP that entirely used procedural code for the
actions, views, and
templates. You could add a new action or view by just adding a new PHP
file in the right
directory with the right name.
You can definitely build something that works along the same lines
that uses OO and
you'd have Symfony or CakePHP or CodeIgniter. I'd say that, however,
the simplest
microframework that implements the action/view/template gives you 50% of the
value that a large framework does.
In that kind of architecture, it would make sense for
authentication to have a close
relationship to the framework. If you've got to write new code to link
the authentication
system to each page on your site, you're going to f* it up, believe me.
An alternative pattern for authentication is to use the "method
that does not return";
usually in web authentication, we redirect a user to a login page if we
find they aren't
logged in. In that case, you can do something like
$auth=new Auth();
$auth->required();
on a page for which authentication is required. The required()
function sends a
redirect header and then calls exit().
The advantage of this is that it's bulletproof against programming
errors on the server
side. If for instance, it returned false or threw an exception, the
security would be
dependent on the outside code doing the right thing. If
$auth->required() kills the
script, it's completely impossible for a programmer using this object
to do the wrong
thing.
Here it can be much harder to override the default manner in which the
exception is handled and add your own method.
BTW, you might also take a look at
http://php.net/manual/en/function.set-exception-handler.php
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
