Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Exceptions and Errors Are Good, Not Evil

DZone's Guide to

Exceptions and Errors Are Good, Not Evil

Exception messages and error handling have come a long way over last 15 years, while debugging capabilities have grown a lot. Let's get over the hate already.

· Performance Zone
Free Resource

Discover 50 of the latest mobile performance statistics with the Ultimate Guide to Digital Experience Monitoring, brought to you in partnership with Catchpoint.

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.

Is your APM strategy broken? This ebook explores the latest in Gartner research to help you learn how to close the end-user experience gap in APM, brought to you in partnership with Catchpoint.

Topics:
exceptions ,debugging ,error handling ,performance

Published at DZone with permission of Nikola Svitlica, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}