13

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?

Community
  • 1
  • 1
Markus Hedlund
  • 23,374
  • 22
  • 80
  • 109
  • 1
    Errors are un-recoverable, and exception are re-tryable. You can't continue after an error, but you can usually ignore an exception. If you can't write to disk, that's an error. If the database won't connect, that's an error. If the environment isn't set, that's an error. But if an API service is down, that's an exception - try again later. Of course your idea of unrecoverable is subjective. – Chloe Nov 16 '16 at 23:32
  • One case for using trigger_error() is when you just want to issue an E_USER_NOTICE or E_USER_WARNING neither of which halts program execution. For example someone using your library sets a parameter that while technically not a program error most likely won't have the desired outcome. Issuing a warning or a notice seems like the right way to handle that instead of halting execution. – PHP Guru Oct 04 '20 at 15:22

3 Answers3

7

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.
Till
  • 22,236
  • 4
  • 59
  • 89
  • Can you clarify "not important to the current request"? If no API key is set, that would be fatal to the current request, I think – Markus Hedlund Oct 22 '10 at 15:39
  • Yeah, an API key that's needed would be an exception thrown. With trigger error, I'd use it if something doesn't validate - or let's say you parse something and the parser issues errors, but you still got whatever you were looking for, more for debugging purposes later. – Till Oct 23 '10 at 08:52
  • Ah, so `trigger_error` is less important, more for logging? That's the opposite of what I was arguing, but I guess it kind of makes sense too. So you never use `try/catch` blocks? – Markus Hedlund Oct 26 '10 at 06:28
2

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.

Marek
  • 7,337
  • 1
  • 22
  • 33
  • if(some_function() == false) { // error, do something } else { // continue normaly } – Marek Oct 24 '10 at 19:18
  • I think you misunderstood me. This isn't catchable, nothing returns `false`. It should be treated as a syntax error – Markus Hedlund Oct 26 '10 at 06:23
  • 2
    You should leave the decision if it's catchable or not to the programmer using your library. And anyway, missing API key is not programming, but configuration error. – Marek Oct 29 '10 at 19:06
  • After I having used it for a while, I have to agree with you. – Markus Hedlund Feb 25 '11 at 21:40
  • 1
    Please always throw exceptions and DO NOT trigger errors! Let the developer decide whether it's catchable or not. The dev might decide for some reason to leave the API key config to the end user. A wrong configuration will render the app unusable with a screen of death instead of being able to show a nice error message to the end user. – wedi Oct 09 '14 at 13:50
1

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.

mway
  • 4,334
  • 3
  • 26
  • 37