What you're describing is exactly the right way to handle errors that you want to trap and try to recover from. However, there is not much point in trapping errors that you can't recover from and don't want to send a specific messae for, like the database being unavailable or the disk being full. (You would want to log that the database was down, but you typically wouldn't want to tell the end user.) For those cases, letting the script die and setting a custom error page for 500 errors is the best approach. | [reply] |
| [reply] |
