NYCPHP Meetup

[Paul A Houle]

  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