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.
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:
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.
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.