Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
add comment

5 Answers

up vote 14 down vote accepted

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

share|improve this answer
    
+1 for reasons behind writing try-catch-finally first –  Kanini Oct 29 '10 at 6:29
1  
In C++, there is no finally, and for very good reasons. RAII is much superior. –  David Thornley Oct 29 '10 at 20:25
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Thanks for the detailed answer. With respect to logging, why would you do start with logging first if I need an Audit Trail. Why can't I write them after I am done with Functionality aspect of it? Any specific reasons? –  Kanini Oct 29 '10 at 16:05
    
To me it is easier to write the logging as you write the functions that need audit, so to do that I need the base logging functions in place before I write anything that would cause me to need them. If I don't write the audit as I go I would be concerned that I would miss something. –  Bill Oct 29 '10 at 16:45
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.