Discuss Exception questions in the PHP Development forum on Dev Shed. Exception questions PHP Development forum discussing coding practices, tips on PHP, and other PHP-related topics. PHP is an open source scripting language that has taken the web development industry by storm.
Posts: 2,237
Time spent in forums: 2 Weeks 1 Day 11 h 3 m 46 sec
Reputation Power: 201
PHP-Security - Exception questions
I have never really "got" the exceptions but I am trying to learn them Now..
I am querying a webservice which returns an exception called "ErrorException" when trying to use its login method.. so am i "correct" in using this approach:
No, it's not correct. Internal error messages are meant for the developers, not the end users. Your users don't need to see your internal bug reports -- in fact, they must not see them, because this could give them critical information and allow them to run specific attacks on your website.
So this whole die($error->getMessage()) is generally nonsense -- I wonder why it's so popular.
When you only display the message, you also lose important info like where the exception occured and which function calls lead to it.
The question is: Why do you even want to catch the exception at that point? Just to write "Connection error:" in front of it? That's kind of pointless.
Only catch an exception if you actually wanna do something with it -- like retrying the action, using a fallback route etc. Otherwise, just let it "bubble up". On the top level (the PHP script called by your webserver), catch all exceptions, write the important data (message, stack trace etc.) into a log file, send a 500 status code and display some generic error message like "An internal error has occured. Our staff is working hard on fixing it. We are so sorry..." yada yada yada.
I seen this from a book that I'm currently reading "Beginning PHP 5.3" and no that isn't a typo for echo is written instead of die. I'm suspecting this isn't as bad as using die, my reasoning (which I'm probably wrong) is the echo doesn't stop the script like die does? Though even then I don't see the purpose of the displaying it, for if it doesn't work it doesn't work.
Posts: 1,875
Time spent in forums: 1 Month 2 Weeks 2 Days 4 h 42 m 18 sec
Reputation Power: 813
Quote:
Originally Posted by paulh1983
part.. i.e. i often get confused what should be put in here so if a webservice returns ErrorException should i put that into the ( ) ..
Yes, you should always catch the specific exception you expect from that bit of code. You can also catch different exceptions in different catch blocks.
But like I said: There's no point in catching an exception if there's nothing you wanna do with it. Logging is done on the top level. It would be insane to repeat the same logging code thousand times for every piece of that that might throw an exception.
---------------
Quote:
Originally Posted by Strider64
I'm suspecting this isn't as bad as using die, my reasoning (which I'm probably wrong) is the echo doesn't stop the script like die does?
It's true that it doesn't stop the script, and that makes it even worse. The script will keep on running until it crashes at the next query with some weird error message talking about a "non-object".
The problem is that many PHP programmers -- obviously even the ones who write books -- aren't familiar with exceptions at all. Exceptions are pretty "new" in PHP, they were only added in 2004. I have the feeling that people somehow try to do the same (bad) things with exceptions like they did with the old error system they're more familiar with.
This ... die($error->getMessage()) reminds me of the equally bad ... or die(show_the_error_message()) often seen in old code.
Posts: 1,875
Time spent in forums: 1 Month 2 Weeks 2 Days 4 h 42 m 18 sec
Reputation Power: 813
Quote:
Originally Posted by gw1500se
Just to continue the useful/uselessness discussion from yesterday. Perhaps, I should have done this to make it clear what the objective was.
OK, now it's no longer dangerous, but it still makes no sense.
I mean, do you want to repeat this try-catch block on every single line of your code? Because I'm pretty sure you wanna track all exceptions and not just this particular one (if not, what happens with the others?).
If you want to specify a global exception handler, make a global try-catch block wrapping all code as explained above:
PHP Code:
<?php
try {
require 'foo';
require 'bar';
...
some_function();
another_function();
...
} catch (Exception $error) {
// if in debug mode, display the message, the stack trace, ...
}
You can do the same thing more elegantly with set_exception_handler. Also have a look at set_error_handler, because this will also fetch the old errors.
Last edited by Jacques1 : March 8th, 2013 at 08:06 AM.
Posts: 2,237
Time spent in forums: 2 Weeks 1 Day 11 h 3 m 46 sec
Reputation Power: 201
jacques.. .can you give me an example of a top level exception handler thing you are on about? because I *see* what you are trying to say.. instead of repeating.. just have it once and that makes lot of sense.. would i do: (from googling)
PHP Code:
set_exception_handler('myException');
login..
if (!login) throw new Exception('Uncaught Exception occurred');
Posts: 1,875
Time spent in forums: 1 Month 2 Weeks 2 Days 4 h 42 m 18 sec
Reputation Power: 813
When you've set the exception handler, it will catch all previously uncaught exception, so you don't need any other try-catch blocks -- unless, of course, you want to handle a specific exception differently.
PHP Code:
<?php
function handle_exception($error) {
header('HTTP/1.1 500 Internal Server Error');
echo 'There was a technical problem. Please try again in 5 minutes.';
// an exception consists of much more than the message, so make sure you also log the other data
error_log($error->getMessage());
}
set_exception_handler('handle_exception');
// test it
throw new Exception('Oops!');
Unfortunately, PHP uses three different ways of indicating bugs: return values, errors and exceptions (exceptions are also errors). So you're probably better off using set_error_handler() to catch all errors (including exceptions).
Note, however, that this completely overrides the default behaviour for errors, so you have to call die() manually to get back the original behaviour. A custom error also can't catch all errors, so you still need to turn display_errors off in your php.ini to prevent the leaking of error messages.
And the return values of course require extra handiwork.
Posts: 7,944
Time spent in forums: 2 Months 10 h 16 m 54 sec
Reputation Power: 7053
Quote:
Apologies if i wasnt clear, the main "thing" i wanted to emphasise was the:
catch (ErrorException $e)
part.. i.e. i often get confused what should be put in here so if a webservice returns ErrorException should i put that into the ( ) ..
The first part (ErrorException) is the name of a PHP class. Exceptions are objects, and as such, they have a class type. $e is just the name of a variable to assign the exception to; you can arbitrarily define this.
The exception will only be caught by that catch block if the type of the exception object is an 'instanceof' of the class defined in the catch block.
For example, catch(Exception $ex) will catch all exceptions, because all exception classes extend the Exception class.
catch(ErrorException $ex) will only catch exceptions of the type ErrorException or subclasses of ErrorException. It would not catch a PDOException for example.
When you throw an exception you are throwing an object. Usually this is reduced to: throw new ErrorException();
But you could just as easily do:
PHP Code:
$ex = new ErrorException;
throw $ex;
Quote:
So this whole die($error->getMessage()) is generally nonsense -- I wonder why it's so popular.
It's popular because when you're writing a tutorial or documentation you want to get rid of as much irrelevant code as possible to avoid using more of the readers' time than necessary. If I'm writing documentation for a webservice with a login method that throws an ErrorException method, it's not relevant to the login() method how the end-user's application handles errors at a global level. Plus, there are dozens of ways of handling errors, and as the documentation writer I have no idea which method a person may be using. Even if I do give an example of global error handling in my documentation code samples, it's going to be useless noise to 90% of the readers.
Quote:
So you're probably better off using set_error_handler() to catch all errors (including exceptions).
Alternatively, you can use an error handler to convert normal errors into exceptions.
Posts: 1,875
Time spent in forums: 1 Month 2 Weeks 2 Days 4 h 42 m 18 sec
Reputation Power: 813
Quote:
Originally Posted by E-Oreo
It's popular because when you're writing a tutorial or documentation you want to get rid of as much irrelevant code as possible to avoid using more of the readers' time than necessary. If I'm writing documentation for a webservice with a login method that throws an ErrorException method, it's not relevant to the login() method how the end-user's application handles errors at a global level. Plus, there are dozens of ways of handling errors, and as the documentation writer I have no idea which method a person may be using. Even if I do give an example of global error handling in my documentation code samples, it's going to be useless noise to 90% of the readers.
Yes, that's why the tutorials writers shouldn't catch the exception at all. It's totally useless in this context and gives people the false impression that somehow every new PDO must be wrapped in a try-catch block and that error handling consists of echoing the internal error message on the website (which exceptions do by default, anyway).
And to be honest: I don't think all those tutorial writers have put as many thoughts into this as you do. They just copy and paste their stuff from someone who has copied and pasted their stuff from someone who has copied and pasted their stuff from someone ... And nobody ever thinks it through.
NOTE: you do not have to handle with try catch right away! you can catch it anytime appropriate. it may make more sense to catch it at a higher level like outside the function that calls the PDO stuff:
[...]
or you may not want to handle the exception with try/catch at all, and have it work much like or die(); does. You can hide the dangerous error messages in production by turning display_errors off and just reading your error log.
Del.icio.us
Digg
Google
Spurl
Blink
Furl
Simpy
Y! MyWeb
Linear Mode
