Exception Handling

I had an argue with the team leader of my ZA-project(the computer-based test application). We are arriving at the integration testing program now, but the application doesn't seems to be that stable. Since we have a lot of interactions with xml parsers, file compressor/decompressor and the web apps(we use jsp for courseware extractions), unexpected exceptions pop up sometimes. Although it's we are working hard in clearing them, the situation appears to be beyond our control.
Usually, the exceptions are about memory access violation and memory leaks. In addition, I found that the application sometimes won't stop when an exception appears not to mention handle it properly before it stands in the way. And after the unhandled exceptions, more horrible problems will come along. We do have defined a set of customed exception classes in a hierachy structure. But I don't see they are correctly used.

I think we should had big problems in exception management. So, in the regular meeting, I suggests that we should strengthen our codes in exception handling. I gave some ideas:

1. Provide a component structure diagrams to show the relationships and the hierachy among among the components to all the team members.
2. Every should mark the possible exceptions in his own module in the diagram. He should give a explicit exception lifetime-line in order to tell the others whether:
1. the exceptions are safely handled within his own module
2. the exceptions are raised for the inability to handle in the current module
3. all the captured system(VCL) exceptions are converted into our defined exceptions
4. all the known user errors are advertised in form of our defined exceptions
3. Everyone uses other team members' components should keep an eye on the exception lifetime information provided by the component author and continue work on it within the range of his own module/component.
4. I strongly advise the team members never handle any handles that should not be handled within their module/level. We've already lost many runtime information by missing these exceptions thus result in the uncontrollable exceptions.

However the team lead doesn't seem to be interested in my suggestions, since he thought this would be a extra burden on the project and he don't believe we can convert ALL VCL exceptions to our defined exception classes. I don't agree with that. I've been told to put a try..except statement every time I need to deal with fileIO/db/network/memRes/... I don't think that would be a burden while it should be a guideline.

I insist on converting all we-have-known vcl exceptions into defined exceptions because I want the upper layer caller would get a well-catagorized problem list to solve or keep. And any we-do-not-know exceptions should not be touched and keep raising to the top layer(UI), at least in our development period, so that we could see what kind of problems there are. When the application is to be released, we could then capture all unsolved exceptions in the most outside layer and change them into a smoother informations instead of the frightening "ding!".

Any way, I'm not supported. But I'll try to work this way in my modules.

After this arguement, I found there are a lot to be thought in the part of exception management. I'm very interested in doing some research on that, but my graduate paper topic has already been set to the ZA project. I think I can try implement an "exception life management tool" which can provide a diagram as I mentioned above in way as UML did. And perhaps the tool could serve as Rational ClearQuest does in the bug-lifetime management.

I've made some small investigation these days to have a look at the development in this field and I found some books and articles.



A discussion
http://dev.csdn.net/article/81200.shtm
http://community.csdn.net/Expert/TopicView3.asp?id=4432545

I will hunt for more related resourse and post them here.

Another dissapointing news is my poor verbal score in GRE test. That wouldn't be an attractive score without which I will no longer have any opportunities to do my interested researches... But I'll not give up. There's still time. I don't have much time prepare for the last GRE test because my whole summer vacation is devoted to the ZA project. But I'll have time for the next June test. Cheer! God Bless.