SignalFx is the only real-time cloud monitoring platform for infrastructure, microservices, and applications. The platform collects metrics and traces across every component in your cloud environment, replacing traditional point tools with a single integrated solution that works across the stack.

I remember that when I started to work as programmer and developer, I hated exceptions and errors. I thought, at that point of time, that anything was better than having your application run into an exception message with some nasty error screen.

Today, the development goal is the same — applications should work flawlessly, as per design, without the appearance of any error screen.

However, the evolution of technology and my maturity as a developer have led me to accept the fact that exceptions and errors have key roles in achieving quality and development productivity. Today, I appreciate exceptions and errors — I almost get excited when I see one.

When Geeks Didn't Rule the World

In order to understand why exceptions were hated, you would have to travel trough time, at least 15 years back. You'd need to see and feel the level of technology in those days, when, for example, you only had Internet Explorer and Netscape Navigator as browsers available, with no decent debugging support from either of them.

Writing JavaScript and tuning CSS was hell. It was mostly based on the try-test approach, while errors in JavaScript were so unreadable and fuzzy that debugging JavaScript was one of the most stressful tasks ever.

Backend/application development was a little less stressful. Most of the time, you had a debugger available, depending on the language and tools you were using. In my 15+ years of development, I have worked with Java, JavaScript, C#, ASP, PHP, VB, as well as a lot of meta-languages and DBMSes — and I remember the most common error message you could stumble upon was something like, "Error 20023 – bad flag at pointer x867580."

If you had a debugger, you could go trough the application execution stack and see what was wrong. If you worked on JavaScript in IE4 or 5, you were screwed. You would get some unrelated error message pointing to the wrong line of code.

No wonder why we hated exceptions and errors.

PHP, as my major language, had the worst implementation of error messages ever. I had a rule in those days that worked most of the time. It was, “If the error message says that A is a problem, 90% of the time, it is actually something completely different.”

The New Era

However, everything changed dramatically fast — in the span of a couple of years. Developers started to dedicate more attention to error messages. They finally realized that developers hate debugging and debugging takes up too much time in the development process.

During my education, I stumbled upon information in conventional literature stating that debugging took more than 50% of the development time. At that point of time, that was really true. Productivity was really low, we were missing sophisticated software tools, bad-ass hardware, and on top of that, we had very fuzzy error messaging supporting error handling.

And — boom! One day, I started my application and got: "RuntimeException on line X in class X: ‘cache_dir’ is not writeable." I changed the perms of the cache dir, and everything worked! That approach of error messages changed everything! The message clearly stated what was really wrong. A new era of errors and exceptions began.

Soon enough, we all implemented this practice. We were pointing directly at the error and telling people how to fix it. If you do your PHP development, for example, in Symfony, you've probably stumbled onto some of the error messages, where the reason for the error is not clear enough in runtime, but the author of the library that threw the exception stated all known possible reasons — just to help you to identify and fix the error.

How Often Do You Use Your Debugger?

I cannot remember the last time I turned on my debugger, honestly. Error messages are getting so clear and comprehensive now, that most of the time, you can identify errors trough the exception messages.

Of course, there are some minor “dirty debugging” practices when it comes to PHP and the environment that includes xdebug:

var_dump($var);
exit;

I do not recommend nor promote that, but I use it often with a 99.99% of success rate in finding errors in a matter of seconds.

Debuggerless Debugging

I believe that we are now entering the era of “debuggerless debugging,” just because authors of vendor libraries do their best to help us understand what went wrong.

Soon enough, errors and exceptions weren't just problems in an application, they were part of the solution. More and more, we throw exceptions whenever we find it suitable to do so, providing as much info about the problem as possible.

To keep it consistent, my team and I have certain coding standards and practices in throwing exceptions that we follow when we code.

SignalFx is built on a massively scalable streaming architecture that applies advanced predictive analytics for real-time problem detection. With its NoSample™ distributed tracing capabilities, SignalFx reliably monitors all transactions across microservices, accurately identifying all anomalies. And through data-science-powered directed troubleshooting SignalFx guides the operator to find the root cause of issues in seconds.