PHP Error Handling – Best Way to Pass Errors Between PHP Pages

Fail fast is a great design approach, and perhaps it can be counted as a pattern: http://en.wikipedia.org/wiki/Fail-fast

I've also found a number of principles to be useful:

• Consider exceptions as part of the interface to each function / modules - i.e. document them and where appropriate / if your language supports it then use checked exceptions.
• Never fudge a failure - if it failed, don't try to continue with some attempt to "assume" how to proceed. For example, special handling for null cases is often a code smell to me: if your method needs a non-null value, it should be throwing an exception immediately if it encounters a null (either NullPointerException or ideally a more descriptive IllegalArgumentException).
• Write unit tests for exceptional cases as well as normal ones - sometimes such tests can be tricky to set up but it is worth it when you want to be sure that your system is robust to failures
• Log at the point where the error was caught and handled (assuming the error was of sufficient severity to be logged) . The reason for this is that it implies you understood the cause and had an approach to handle the error, so you can make the log message meaningful.....
• Use exceptions only for truly unexpected conditions/failures. If your function "fails" in a way that is actually expected (e.g. polling to see if more input is available, and finding none) then it should return a normal response ("no input available"), not throw an exception
• Fail gracefully (credit to Steven Lowe!) - clean up before terminating if at all possible, typically by unwinding changes, rolling back transaction or freeing resources in a "finally" statement or equivalent. The clean-up should ideally happen at the same level at which the resources were committed for the sake of clarity and logical consistency.
• If you have to fail, fail loudly - an exception that no part of your code was able to handle (i.e. percolated to the top level without being caught + handled) should cause an immediate, loud and visible failure that directs your attention to it. I typically halt the program or task and write a full exception report to System.out.

Is it good practice to use exceptions and throw/catch exceptions rather than returning 0 or 1 from functions and then using if/else to handle the errors. Thus, making it easier to inform the user about the issue.

No, no, no!

Don't mix exceptions and errors. Exceptions are, well, exceptional. Errors are not. When you ask a user to enter a quantity of a product, and the user enters "hello", it's an error. It's not an exception: there is nothing exceptional in seeing an invalid input from the user. Why can't you use exceptions in non-exceptional cases, like when validating input? Other people explained it already, and shown a valid alternative for input validation.

This also means that the user don't care about your exceptions, and showing the exceptions is both unfriendly and dangerous. For example, an exception during an execution of an SQL query often reveals the query itself. Are you sure you want to take a risk to show such message to everyone?

more than 1 thing could go wrong, such as a database issue, a duplicate entry, a server issue, etc. When an issue happens during registration the user needs to know about it.

Wrong. As a user, I don't need to know your database issues, duplicate entries, etc. I really don't care about your problems. What I do need to know is that I entered a username which already exist. As already said, a wrong input from me must trigger an error, not an exception.

How to output those errors? It depends on the context. For an already used username, I would like to see a small red flag appearing near the username, before even submitting the form, saying that the username is already used. With no JavaScript, the same flag must appear after submission.

For other errors, you would show a full page with an error, or choose another way to inform the user that something went wrong (for example a message which will appear, then fade away at the top of the page). The question is then related more to user experience than to programming.

From programmers point of view, depending of the type of the error, you will propagate it in different ways. For example, in a case of a username already taken, an AJAX request to http://example.com/?ajax=1&user-exists=John will return a JSON object indicating:

• That the user already exists,
• The error message to show to the user.

The second point is important: you want to be sure that the same message appear both when submitting the form with JavaScript disabled and typing a duplicate username with JavaScript enabled. You don't want to duplicate the text of the error message in server-side source code and in JavaScript!

This is actually the technique used by Stack Exhange websites. For example if I try to upvote my own answer, the AJAX response contains the error to display:

{"Success":false,"Warning":false,"NewScore":0,"Message":"You can't vote for your own post.",
"Refresh":false}

You can also choose another approach, and preset the errors in the HTML page before the form is filled. Pros: you don't have to send the error message in AJAX response. Cons: what about accessibility? Try to browse the page without CSS, and you'll see all the possible errors appear.