#Suphle Rant 9: verbatim exception scare

In multiple rants, I've bitched about laravel stealing suphle features. By some very weird coincidence, it appears I've been given a taste of my own medicine. Let me explain:

We're having a chat this morning on a laravel group chat when someone says he uses their notification component a great deal. Curious, I ask him what he uses it for since I only used it sparingly during my laravel days. To pry an answer out of him, I ask whether he uses them for sending app error alerts to a slack channel, and he responds with an eerily familiar term. I quickly look it up and the results on the docs are chilling: errors can be sent to bugsnag (which suphle has an integration for), sentry and Co. Errors can either be broadcast or disabled. Specific kinds of errors can be caught. My heart sunk. My brother called for something while I was going through it and I was struggling to pull myself together

Their exception component is almost identical to mine and I'm only just realising. It's shameful that I'm just learning about functionality present since 5.8. I thought my creation was novel. BUT! The good news is, the implementation differs

Too many errors went unnoticed during my time there because error broadcasting is optional. Since none of my colleagues read that part of the documentation, we were firefighting by pulling and wrangling production error logs. This informed their abolishment in suphle altogether

A relatively minor difference is in the APIs –their philosophy makes significant use of global functions, violating SRP, etc.

But the most important difference, that still cheers me up, is that they only catch known errors. Suphle has a construct for isolating calls to a decorated service. Any unforeseen error to occur during its execution will do a series of things before control is returned to the caller