trigger_error vs. throwing exceptions

Question

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?

Answer 1

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:

1. The HTTP client library throws an exception when the actual request failed -- e.g. due to a connection issue, such as a timeout, etc.. Of course I catch this error, but I don't elevate it to the user. My wrapper returns false and this equals to, "Temporary issue." in the frontend.
2. In my catch() block I use trigger_error() to log debug information about the actual connection error. Since I got error_log = syslog in my php.ini all this information is send to syslog and eventually to my log master.