In this page , I will explain the design policy when an exception occurs.
The exception handling is necessary regardless of the object-oriented design and programming. Then , because I thought that it was not a content suitable in this contents , I had not written at long time.
But , because the amount of the design and programming source code of the exception handling is often more than that of the normal processing, and because it is important , I will explain.
I don't know the strict definition, but I think that it is to become impossible to execute the normal processing.
The following are the typical causes of the exception.
User's input mistake is detected.
The file is not found.
Failure of the accessing (writing or reading) to the file.
Note : Of course , because you can define the causes , there are many other too.
The first "User's input mistake is detected." might not be included in the exception.
This is dependent on the policy of the system development.
( Note : Even if it is not included in the exception , this doesn't mean that "User's input mistake is detected." is not needed. )
When an exception occurs , what should the program do ? I think the following.
The case of user's input mistake
in this case , to tell the solution and the cause of the mistake is important.
The case of others
In this case , the typical causes are the specification bug , the program bug or the defect of the execution environment.
The program should release the acquired resources ( memory , mutex , thread and so on ).
For example , release the heap memory , close the DB connection , and close the file. Other , unlock the mutex , delete the thread and so on.
If not released , the status ( of this program and other program ) may become worse.
The program should tell the user the occurrence of the exception.
Because the occurrence of the exception is the failure of the process that the user required.
But , the problem is what information how many details is given.
To be often said is that the user can understand "What should the user do?".
But , This is often "Please inquire of the system administrator."...
The program should record occurrence of the exception on log files.
If this doesn't exist, you can not analyze after. if you can not analyze , you can not take a measure.
I think that the information of the log should contains the occurrence date and the cause.
For example , as java.lang.Throwable.printStackTrace() method in Java language , I think that the trace ( the class name , file name , method name and line number ) should be contained. But if unsupported , that is difficult.
The program should save a backup. Of course , it must not destroy or delete the datas.
If the datas is saved , you can restor.
The program should send a mail to the system administrator...
My murmur : No-----.
Then , in this case , solid design is needed.
Because the influence of the system condition ( disk size , network speed and so on ) needs considering , and requirement amount is dependent on the system. And , if the amount is increased , the cost become increased , therefore , the compromise is needed. And , because an exception occurs in the exception handling too , it is unexpectedly annoying.
Finally , I will describe 2 points.
1. Because the prohibited matters in the exception handling is written in the book of the Anti-pattern , please read books.
(For example , there are The Man with the Axe anti-pattern , Ignoring Reality anti-pattern)
2. You should design supposing that an excepiton occurs. "It is likely not to occur." is very denger. I repeat , the amount of the design and programming source code of the exception handling is often more than that of the normal processing. There is a case that you can't design an exception handling well. In this case , you may think that you define the limitation.
I doesn't assume the responsibility of any damage that occurs because of the use of this page.
Visual Basic® for Applications may represent a VBA.
Mac ,Mac OS ,Mac OS X ,AppleScript are trademarks of Apple Inc., registerd in the U.S. and other countries.
Sun, Sun Microsystems, Sun Microsystems Computer Corporation, the Sun logo, the Sun Microsystems Computer Corporation logo, Solaris, Java, JavaSoft, JavaScript, HotJava, JDK, and all Java-based trademarks or logos are trademarks or registered trademarks of Sun Microsystems, Inc.
Other brands and their products are trademarks or registered trademarks of their respective holders and should be noted as such.
The author of this page and these companies do not have any relationship.
