2

What if the programmer uses Exceptions for debugging? Would it be better in that case to just report the failure and immediately interrupt the script since ideally all bugs should be fixed radically?

Is this a correct way of using exceptions in PHP?

Related reading: exceptions in PHP

Thanks

  • it resumes the script after the last catch block of the current try -- This doesn't seem correct. When an exception is thrown, the original "script" is abandoned. – Robert Harvey Jun 5 '15 at 17:44
  • this is why it says the script is resumed after the last catch block – mikl Jun 5 '15 at 17:46
  • But it isn't. Execution aborts at the place where the exception is thrown, and control is not returned to the original script. – Robert Harvey Jun 5 '15 at 17:47
  • True, i had that wrong, i edit my question – mikl Jun 5 '15 at 17:50
3

What you're probably looking for are assertions, not exceptions.

In general, exceptions should be thrown when something bad is happening that you can't do anything about in the current code scope. For example, your function's purpose is to open a file, but the file specified in the function's parameter is not present on the storage medium.

Exceptions shouldn't be used as a generalized debug mechanism. If you want to know whether something is happening or not in a script, log it, capture the behavior in a unit test, or examine it using a debugger, rather than using an exception.

Exceptions signal something that you expect to happen, even though it's an error condition that you cannot do anything about. You might reasonably expect that someone will hand you the path to a file that does not exist. But that doesn't mean that your code is incorrect; it just means that the caller didn't provide adequate conditions to succeed.

Assertions are different; they signal a problem with your code. They are more semantically correct to use for debugging purposes than exceptions, which have a different purpose.

  • So by "something bad" do you mean fatal errors? And why "Exceptions shouldn't be used as a generalized debug mechanism"? Would appreciate just a brief explanation or a reference. – mikl Jun 5 '15 at 18:13
  • See my edit.... – Robert Harvey Jun 5 '15 at 18:21
0

It depends

Based on what your application is doing and the necessity of the function that threw the exception will determine whether to fail immediately or continue processing.

For instance:

Scenario 1:

User attempts to update their password.

Password hashing function fails and throws an exception

In this case the application should interrupt immediately and display an error to the user.

Scenario 2:

User is navigating through site, interacting normally

Process updates last seen timestamp (ie- this user was last seen 5 minutes ago...)

Update fails and throws an exception

In this case, I would argue, the application should fail silently (but still logging the issue) and continue working as normal from the user's point of view.

Essentially, if critical functionality is broken due to an exception, interrupt immediately, otherwise gracefully degrade (and log).

0

This is not specific to PHP, so I will answer the general case.

There are two types of failures in web applications:

  1. Script failed to initialize. Examples: could not connect to database; required header file not found; other fatal error.

  2. Script initialized, but there is an error condition in the business logic. Examples: user enters incorrect password.

In the first case there is not much you can do to handle the error other than put up a generic white page saying "sorry, site's broke." In the second case you can easily trap the error and output something meaningful to the user even if it is "sorry, can't do that, try something else."

If you cannot continue processing due to a fatal error, kill the page. Cut your losses and go home. If you can continue processing, then do so.

But, what if the programmer uses Exceptions for debugging?

Why would you put in special exceptions for debugging in production? Sure, go ahead and throw random exceptions in dev or test to test your error-handling logic, but in production you want to be as safe as possible. Specifically for web applications, this means:

  • Never leak sensitive data such as filesystem paths, file names (e.g. *.inc files in PHP), or database credentials.

  • Never leak database schema information even for known applications (e.g. WordPress or other open-source web applications).

  • Never leak variable names or other internal data that may give an attacker clues as to how to exploit your web application.

  • Never output unsanitized data.

  • Always try to give the user an out: can you at least spit out a link to make it easy to retry the operation or go to a safe page (e.g. /)?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.