NYCPHP Meetup

[Marcin Suterski]

I'm from the school where exceptions are for moments where something happened that a normal execution flow would not expect, like incorrect json format in the response from API. Or user tried to access restricted content without being authorized. 

On the other hand, something like authorization failure from login form is what login flow expects to happen and would be handled with error message. 

If something exceptional happened you probably want to break your flow and handle it somehow. If you don't have to it means it was something you expected might happen.

As for depreciated functions and internal errors it probably depends on what path particular framework is following, exceptions or error values. Worst thing is when it implements both in different modules. Personally, I prefer exception in this case to give me faster feedback. 

Marcin


On Jun 23, 2011, at 11:04 PM, Gary Mort <garyamort at gmail.com> wrote:

> I'm confused on the difference in common PHP usage between when one
> should use an exception and when one should use an error.
> 
> Most of my confusion comes from the fact that the way both Exceptions
> and Errors are handled and generated in PHP has changed over the years,
> with each one being used at times incorrectly because the other did not
> have all the functionality needed for particular usages.
> 
> So, to review what my understanding is as of PHP 5.3:
> 
> When an error is generated in PHP, there are a number of pre-defined
> types of errors:
> http://www.php.net/manual/en/errorfunc.constants.php
> 
> What are especially useful for programmers is differentiating between:
> Depreciated, Notice, Warning, & Error.
> 
> As of PHP 5.3 all of the above error levels have both a PHP error level
> and a "user" error level.  An example of the difference between them
> could be that when running a program that utilizes a PHP framework, if
> at some point in the code there is a call to the split() function - the
> program will execute correctly, however a depreciated error will be
> generated and if such errors are logged, periodic review of logfiles
> will give programmers a heads up that they have to recode part of the
> program.   Wheras if that framework defines it's own internal functions,
> and one function is slated to be removed, good programming practice
> would be for the framework authors to generate a user_depreciated error
> notice - which can be used in the same manner to update code using that
> framework.
> 
> When user errors are generated in PHP, the program may or may not abort
> when the error is generated.  It may or may not log the error message to
> a file or some other method.  All of this depends primarily on how the
> PHP instance is configured.
> 
> This makes user errors great for providing information about potential
> problems with the code when you are not sure whether or not the error
> should result in the program aborting or just noting a transitory problem.
> 
> 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.
> 
> 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. 
> 
> Error handling: the page can be completely generated by one function. 
> First the header is sent, then the authorization for the main section is
> checked - if it fails, an error can be generated and an unauthorized
> message generated for display, if it succeeds the data can be generated
> - then the footer is sent.  The user of the application can decide that
> they want to do something different[lock the account, abort handling,
> call the cops] by creating their own error handler function and calling
> it before they call the third party code. 
> 
> 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.
> 
> Here it can be much harder to override the default manner in which the
> exception is handled and add your own method.
> 
> So what I'm curious regarding is how are these 2 methods used in
> practice today, as opposed to theory.  Especially when considering the
> use of frameworks where you don't expect a single team of programmers to
> be writing all the code -but rather you are building on an existing
> framework which can generate it's own errors and exceptions.
> 
> -Gary
> 
> 
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
> 
> http://www.nyphp.org/Show-Participation