Can I postpone Exception Handling to the end of a project?

Question

I am developing a .NET application, in C#, with the help of an external consultant. It is our goal to have this project as a test case for a better development process, paying special atention to best practices (so as to produce a proper Software Product instead of just a Program).

Currently, we are in doubt between paying more atention (and wasting more time) developing Exception Handling and Logging infra-structure, or developing the proper Architecture and Functionality of the application (which has already been analyzed and modeled).

So the question is: Does Exception Handling have to be built alongside the application development, or can I just program away and, when things are a bit more ready, I "apply" error handling and exception management code over the program?

This is quite a small and well-understood application, with a well-understood architecture, but we're afraid that too much work will be redone if we don't make a proper choice regarding infra-structure and cross-cutting concerns from the beginning (that is, while most of the code hasn't been written yet).

Another point is: we're not sure if we would use some framework for that or not, and if yes, which one would it be. So, if this is not fundamental, we could develop the rest of the application and come to that later on.

Answer 1

It is our goal to have this project as a test case for a better development process

So if you are thinking for a better development process then handling the error would be better approach as you can catch the exception and improve upon them then and there.

Answer 2

In my opinion, time spent doing proper Exception handling and logging is never wasted -- it's time invested in a good product. Thinking you're developing the proper "Architecture and Functionality" is all well and good, but a locked file is a locked file and an unplugged network cable is still unplugged no matter how clever your program is. As far as logging goes, again, you won't think you need it, and maybe you really won't, so one school of thought says add it when needed. On the other hand, once the product is in the field it's a lot easier to tell a customer, "Set this setting and send us the log", than "Gee, heck if I know".

Frameworks are optional and I'd be inclined to skip them -- .NET itself has excellent support for both logging and exception handling. But you might take a look at Log4net before you make up your mind.