When to start writing Exception Handling, Logging

Question

When do you start writing your Exception Handling Code? When do you start writing Logging Statements.

For the purpose of elaborating this question, let us assume that we are on .NET platform with log4net logging but feel free to answer in a generic way.

Solution: A Windows Forms Project. Projects: UI, BusinessRules, DataHandlers

So, do you go about writing your DataHandlers which does your Data Manipulations such as Create, Read, Update, Delete first.

Then follow it up with your Business Rules

And then your UI or any other permutation of the above.

Test your Application for Functionality.

And then start writing your Exception Handling Code and finally your Logging code?

When is a right time to start writing your Exception Handling code?

PS: In the book Clean Code, they say Write your try-catch-finally block first. That, prompted me to ask this question.

Answer 1

You write your exception handling code when you're writing the thing that calls something that might cause exceptions.

For instance, when you're writing something that sends data to a network, you should also be writing the code that handles connection timeouts. The exception's directly relevant to what you're doing, and the work is fresh in your mind.

On the other hand, if you're writing a parser that raises exceptions when it encounters a malformed protocol data unit, then you can't write exception-handling code for the exceptions that parser produces. (But of course you're writing tests to show how and when and why the parser raises exceptions!)

The reason behind the suggestion to write your try-catch-finally first is two-fold: finally is for cleaning up the resources the function creates/consumes, and writing the catch is a nice reminder that the functions you're calling may fail, and you need to handle (if necessary) those failures.

I tend to add logging after the fact. I'm not sure if that's wise, but it's just what has worked for me. As I start running acceptance tests and the like, and start hitting issues, then I add logging so I can track errors. (And then I leave the logging in.)

Answer 2

In my experience, if you don't write code with the appropriate error handling and logging from the beginning, it won't get done due to time pressures. The most successful development efforts I have been on started out with time spent determining basic application structure, including coding standard, how errors would be handled, logging, basic architecture and test tools.

Otherwise, you'll find that you have tasks for version 2.0 like "Improve error handling" and "create logging system". These will be cut in favor of new features, and because you have "too much to do", fixing all those bugs in the error cases you didn't think about. (Which takes forever, because you have no logging system.

Answer 3

Depends on what you are doing

for exceptions:

If you are writing something that is likely to have errors or something where there are good top level points to let exceptions bubble up to write them as you go.

If you are writing something that needs performance and has a low possibility of errors an lacks a meaningful place to put error handlers write the error handlers where testing proves you need them.

In either case, if you don't have anything useful to do with the error consider letting it bubble up (no handler)

for logging:

If you need an audit trail you should write the logging first. If you are letting errors bubble all the way to the top you need to provide some logging there as well so the log can be captured.

Aside from those cases I generally only add logging in the places where testing/use proves it is necessary and I usually make an option to configure it off once I am done with it.

Answer 4

You can implement auditing and exception handling as services. Application-level audit logging requires status data about each business transaction. The ability to monitor an application in a business or transactional context requires a monitoring interface within the service to send messages detailing the transaction's status specific to the service invocation. This requires each service to send a status message at critical steps in the business transaction. You can then build a real-time viewer to correlate status messages (based on the semantics of the message - e.g. transaction ID) with the services within the composite application. This provides an end-to-end view of the business transaction for SLA management, fault tracing and problem determination.

An audit service can then be implemented as a state machine that can consume and record messages based on criteria defined in its configuration. A generic exception handler can also use the audit service to support a centralized view of problems that occur in the enterprise SOA - to support exception-based monitoring. Any should-not-occur condition in the solution is instrumented to send an exception message to the exception handler.

Answer 5

Write it when you need it, but design for their inclusion from the start.

In other words: make it so there is a way to handle that logging capability, and add the actual nuts and bolts functionality (what messages it logs) later as the need arises. On exceptions- add the catch(and finally if you've got that) before you write the throw. That will help to keep from forgetting one and saving yourself an iteration or at worst a bug/crash.