A similar question was asked here, but as the answers didn't answer my question, I'm asking:
I've almost never used trigger_error
, always thrown exceptions instead, since in my mind errors are legacy. But I've changed my mind, I think they can co-exist. There are cases when triggering errors make more sense.
I'm updating this library, this question concerns the send
method, but is general enough. This is my reasoning:
If an API key constant is not set, that is not a catchable error. That is a programming error, and should be treated as such.
If an email address is invalid, that should be catchable. This is most likely a user error.
Am I loco? Is this unnecessary and annoying, or does it make sense?
If I'd use the library, I would really hate to use both try-catch block and old style error checking. And even if the missing API key renders the library unusable, it's still part of application.
I agree with your distinction, as to when to throw and when to trigger. For me,
trigger_error
is also something you want to make a note off, but it's not important to the current request. E.g. for debugging purposes.Since all my PHP errors (note: not exceptions, but warnings, notices, fatals, etc.) are logged in production, I think
trigger_error
is a convenient way to get stuff into said log.Here is an example:
I'm using a HTTP client to access an API we integrate. Of course the library I use is object-oriented PHP and therefor makes heavy use of exceptions. I'm doing various things here and I hope this example makes sense:
catch()
block I usetrigger_error()
to log debug information about the actual connection error. Since I goterror_log = syslog
in myphp.ini
all this information is send to syslog and eventually to my log master.They both have their uses. Generally, I gear trigger_error() toward developers, since in most production environments error reporting is turned off; then, since most application errors would likely be from bad user input or undesired results based upon user input/actions, I throw exceptions to keep better control over the application (handling those exceptions in a way that both allows the app to recover, and (if necessary) informs the user about what happened in a logical way.
Edit: that example was based off of web apps; the same could be said of any piece of variable data in a non-user-controlled application.