Throwing an Exception (and a Party)

It should work if you try it again :). It looks like the temporary machine we create for you had shutdown *right* as you answered the question (for security, the machines are temporary - we try to keep them alive, but they have a max life of 20 minutes). Sorry you hit that - I got a report in our logs about it actually - it happens occasionally (that a user submits *right* when it shuts down).

Right, I got that message (and refreshed I think...) Anyway: Challenge done :)

Hey Max!

In practice, not really. But GREAT question - and I realize that are example isn't the best for answering this :). Most of the time I just call functions and *allow* them to throw an exception (which *will* cause an error on the page). The reason is that most exceptions are... quite exceptional and rare. In the rare cases that something crazy happens, I actually *do* want the exception to be thrown and "uncaught" so that the page has an error. Since I use Symfony, I configure my framework to send me messages (I do this via Slack) whenever there is an exception. That way, yes, one user might see an error (like the 502 error that you saw on the challenge) but I'm notified :). If you try/catch everything, and try to recover, even when something crazy is happening, it's not really a great policy.

In reality, you should use a try-catch when you know that you might call a method, and it might throw an exception under some reasonable/normal conditions. I'll give you 2 examples from our site :).

1) We use Stripe for ecommerce. When you talk to Stripe's API using their PHP library, and a credit card is declined, their library throws a Stripe\Card\Error exception. Since that's a normal/predictable situation, we catch that error and show the user a really nice error.

2) We use Guzzle in many places to make API requests to other sites. Occasionally, we make a request to a site and we *know* that the endpoint *might* return a 400 status code instead of 200 under normal conditions (the details why this is normal for us aren't important - the point is, we *expect* this behavior sometimes). Guzzle throws an exception when a 400 status is returned. So, we try-catch those calls so that we can take action when the status is 400.

So you really need to ask could calling this function under normal conditions result in a predictable exception? Or would an exception happen only in crazy situations. The example in this chapter would actually be a case where I would *not* catch the exception... unless you're having crazy database situations where you expect your database to fail routinely (which is not a great situation).

Cheers!

Wow! Thank you so much for this detailed and helpful explanation! I'm going to use the try-catch-possibility wisely ;)