Note: For visitors of your site, this entry is only displayed for users with the preselected language English/English (en)

As part of an ongoing discussion with a developer (let's call him JDOAGD) I am paired with, I had the opportunity to discuss the importance of Error Handling within an application. The two sides:

• Minimalist -- only at the UI layer, and only then when the code is likely to fail
• Solid -- Assume errors can happen anywhere, and handle them gracefully at ALL layers of a multiple application.

There's a school of thought that when an error condition occurs, throw an error or bubble it up to the highest layer and handle it. OK, that's a strategy, but what happens when the top layer doesn't catch the error? Crash. Fortunately, I was able to demonstrate this fact to the developer today who adamantly insisted on handling it at the UI only. He forgot to handle it, and BAM!, a crash ensued.

I wish I felt this was isolated, but I have had the privledge of working with several hundred developers over the past 10 years, and I would guess error handling is one of the most overlooked aspects of an architecture. Of those hundreds of developers, I would venture error trapping and handling was considered an afterthought by 90% of them. Some examples:

• Degrades performance, so why do it? (how about a dead app really performs slow)
• The applicaion is for internal customers, so they are more forgiving than if we were trying to deploy for general release
• What's error handling and logging?

I recall a project which I was brought into a few years ago. The 4 developers had spent a month learning the business rules involved, and were chomping at the bit to get started. When I came in, they mentioned they were ready to code. So, I asked a few obvious (or so I thought) questions so I too would know how to code with them.

• What's the error handling strategy?
• What's the data access strategy?
• What's the physical architecture?
• What type of security model are we implementing?
• ...and many more.

Scary thing was, they didn't have an answer for any of them. The other scary thing was they were billed as “Expert Coders” and were billing at a significantly higher rate than myself. Had I less ethics, I would have asked for more $$ instead of pushing to resolve these issues. That whole project was “interesting” to say the least and someday I might write more about those experiences.

Back to today. So, since I am on their payroll, I listened to JDOAGD's reasons for not having error handling except on the UI layer. I watched him also forget to place any at the UI level he was so adament about it. I had the hook, and he finally saw the light. What was my point?

In a multiple developer environment, you can never assume the other develper using your code will trap the error (this is an encapsulation issue, which this same developer once vehemently added encapsulation was a bad thing. In a non-web environment, crashes kill the application. The browser is very forgiving!

Finally, internal or not, as developers we are serving customers. Without them, we'd have no jobs. It's important to ALWAYS give them the best possible user experience. Anything else is simply lazy and unprofessional.

Logging is a whole other issue, which I will save for a future session. For now, I'd love to hear other opinions and experiences in this area, so please, drop me a comment!

-- Daryl