开发者

Exception messages in PHP

开发者 https://www.devze.com 2023-04-12 23:29 出处:网络
Usually a PHP application has an user interface. In a MVC layered application you might throw some exceptions.

Usually a PHP application has an user interface. In a MVC layered application you might throw some exceptions.

What type of message do you set in the exception:

A)

    开发者_高级运维
  • a custom message to display to the user
  • and you log the error with technical details before throwing it

B)

  • a custom technical error and a custom exception
  • no logging near the exception
  • catch the exception, log the error and display a custom user message based on exception type

C) other variants


Users should see no errors or exceptions at all.

If something goes wrong, log it, maybe mail it to yourself, but don't show it to the user, just go on as if nothing happened

That's why production sites have error_reporting off


General Practice

C - You should only record backtrace when error happens, because you won't be able to recover it. You catch error message inside your Application class and then depending on the setting either display message or log it and display some sort of generic screen to the user.

When logging error, add more information such as browser version, ip address, URL requested.

User-friendly messages

Inside my Models I sometimes throw "ForUser" type exceptions. Those don't record backtrace and when caught by the Application class they are displayed to the user. There are few exception sub-classes to that such as Validation, Logic etc.

Re-Throwing exceptions

Some UI elements detect exceptions to properly display them, such as form submission would call Model->update(), catches validation exceptions and shows them for appropriate field inside my Ajax form.


B - That's the way i'd do it. There is a further consideration around ajax and throwing exceptions. If you have a rich UI with lots of javascript then I recommend that that you throw different exceptions with different status codes (http responses) and then display different messages depending on those responses.

You may also want to handle the exception differently in different environments. In development you may want to display the exception and show a stack trace.

On live you may want to display your 404 page or have a catch all 500 page for all exceptions.


Exceptions and errors are for the developers only (or other applications interacting with your application)

In php, a common practice is to create an error handler (I like turning errors into exceptions) and an exception handler (for uncaught exceptions)

In the development enviroment, you would see the full exception message, and a backtrace.

In production, the handler turns the exception into a user-friendly message, with no sensitive details at all. Maybe all you want them to know is that 'something went wrong', and you want that message to be embedded in the same layout you use for the rest of your site. Try going to any decent site and do something wrong, like going to a non-existent url. You will probably find a nice 404 page, instead of 'exception: url does not exist' or something like that.

Also, you may want different error logging levels depending on which enviroment you are in. In development you want to log all the errors, warnings, info messages, an debug messages. In production, you might want only the errors (and maybe warnings) to be logged.

Setting all this up can be very tricky. That's why we have frameworks to deal with this kind of tasks. You should try Symfony 2

0

精彩评论

暂无评论...
验证码 换一张
取 消