I've heard bad things about it, like the suggestion that PHP's implementation of it is poor (example below):
Code: Select all
<?php
try {
unlink("secret/secret.txt");
} catch(Exception $e) {
print "whoops!";
}
?>
Warning: unlink(): SAFE MODE Restriction in effect. The script whose uid/gid is 501/501 is not allowed to access /home/xxx/secret owned by uid/gid 0/0 in /home/xxx/test.php on line 4
Eg, you'll never see the 'whoops!' message. Now, I'm trying to get my head around when to use this kind of structure, particularly if it's not as predictable as you'd hope. At the moment, my approach to programming interfaces where things can go wrong (eg, user submits a complex form including file uploads) is just like this:
- user submits form
- form fields which are required are checked for presence
- if any of the above are left empty, an error message is stored in a $_SESSION var and they're redirected to the form (to prevent clicking refresh and resubmitting etc) with their $_POST values intact
- same goes for any other errors, eg wrong filetype, upload error etc
- if all goes well, data is saved and redirect them to success page
What's wrong with this sort of approach? Do I 'need' to structure all of this in try/catch blocks to be considered a good programmer? Is there any advantage to doing it that way?
Thanks,
Matt