The real subject of this might well be the usage of exceptions, but first I wanted to discuss design control so that the usage of exceptions can be placed in perspective.

I do not have a clear picture of how the Design Control process is carried out in Computer Science. My own background is engineering (chemical) and the Design Control process is very robust and is The integral piece in the design/development of any system of any type. I have been going through some documentation for software system (application) design and have not been able to find anything that I would consider to be an adequate Design Control Process. That does not mean it does not exist, but just that I have not found them. I am aware that there are some out there, GAMP comes to mind, but I have never been a fan of GAMP (it's personal). However, I have implemented many software systems into many chemical production systems over the years and have had some experience with software system design control. So that is the background for my real subject which is FMEA (Failure Mode Effects and Analysis) and the usage of exceptions.

For those of you who might not be familiar with FMEA's and their usage let me explain. The short explanation is that an FMEA is formal documentation of everyone's best idea of what can fail in a system being designed (prior to even starting the design) and how to remediate/resolve those failure modes. The FMEA is updated as the design goes forward. I have reached a point in my learning of software system design that I am now thinking about how to carry out a formal Design Control for the applications I am attempting to develop.

To that end I have found myself beginning to use exceptions as not just a debugging tool, but as part of remediation for identified failure modes. I have identified two primary types of failure modes in the software systems I am working on or have observed. The first are those failure modes that occur in the operation of the software system, i.e. contamination of the code causing an error. The other type is user interactions with the software system, i.e. the entry of the wrong type of data into an input.

I have lately been using a lot of Try/Catch exceptions for both debugging and for remediation of certain failure modes. What the Try/Catch offers is the ability to, when an failure occurs, provide a means to continue the application without it breaking down and, where possible, to provide a means of correcting the failure. However, what concerns me is the cost (in application efficiency) that using these might entail.

Now I have an application that has a rather large number of Try/Catch routines for debugging purposes and for failure remediation purposes. The first case really is to cover all of those failure modes that might fit into the software operation type. Certainly they can be taken out when the design/development is complete, but I would prefer to leave them in, in the event that something might effect the code at critical points in the running of the applications. The second case is the user interface failure modes, and I would very much prefer to keep all of those them in for those.

It is my understanding that the efficiency of the application can be reduced (in terms of an increase in processing time) to use Try/Catches as a remediation tool, which slowly and painfully brought us to the simple and seminal question I have. It is my understanding that using the Try/Catch methods can increase processing time. What I most need to understand about this is that unless the Try fails and the Catch is executed how is processing time increased? It seems to me that processing time should only increase when the Catch is executed. Is this true?