This basically dump everything to an email.

This is what we do as well. I'm sure someone will be along to tell us it's a bad practice, lol, but, its the fastest way to learn about an error and gives us exactly what we want.

Yes indeed. Since the email ONLY comes to me, it works. For larger projects that encompass more people, Sentry is the way to go.

@Adam Palcich… I’ll be that guy. While email is ok for something small, it is inherently unsustainable. Some issues w/ email off the top of my head. • Reliant on a viable recipient to deal with error. • Can easily become white-noise. • Inability to see trends / number of times a specific error has happened. • Error is lost if email can’t be sent • In the code example, what if the app var doesn’t exist? Ideally, you should log the errors to a db or even a file. Put them where they can be viewed/tracked by anyone that needs too. Try and send an email that an error happened but don’t rely on that as the sole means for error reporting. Also, I believe that your error trapping/reporting shouldn’t rely on anything to exist outside of the error function itself. What if the error is that your email system is out?

@dfgrumpy I 100% agree with everything you've said, lol. We know its a bad practice and hate ourselves for it. We used to have Splunk for log consolidation, but lost it due to some budget cuts back in the day and were forced to get creative. As they say, there is nothing more permanent than a temporary solution.