This link has been bookmarked by 3 people . It was first bookmarked on 30 May 2007, by someone privately.
-
05 Jun 07
-
- errors in programs or program parts do occur because of a flaw in programming or incorrect input to the program / program part. Assuming we only take a single method call retrieving parameters, the following conditions which result in wrong output can be classified:
- The parameters given to the method are not well defined (i.e. are wrong or empty / null where they must not be)
- The "constellation" of the parameter values are not expected in the given way by the method (because if parameter "a" has a certain value, "b" must not be of another certain value)
- The caller of the method simply calls it in an improper way (i.e. the environmental conditions are not correct, needed resources are not allocated yet etc.)
- The method allocates external resources (i.e. open connections, file handles etc.) and does not free them (thus leading to an invalid internal state of the program, the operating system or other components like databases)
- The method relies on external resources (i.e. file system, database etc.) which are not available at the moment they are needed
- The method and therefor it's programming trusts on an internal state that is not correct (i.e. corrupt data/instances needed to compute the result)
- The method contains a programming error
- The parameters given to the method are not well defined (i.e. are wrong or empty / null where they must not be)
-
And never forget: If you decide to throw an exception, be as precise about the error as you can be. If your language accepts an error message to pass with the exception, make it as accurate as possible. If the language allows to specify different exceptions or even subclass exceptions, be as precise in selecting the type of the exception as possible.
-
Do not listen to people who argue that exceptions are (time-)expensive. Firstly they are right, no argument needed. But the benefit of clear, more stable and readable code leaves enough time for you to optimize your algorithms on other places more needed. Remember that exceptions represent "exceptional behaviour", they represent erronous states which only happen in special erronous cases. Ordinary spoken: If you do not throw exceptions to just simply leave a loop or code block you will be fine on the performance side of life.
-
Checked exceptions are exceptions you have to catch or, via definition, throw up to the next ("calling") instance. A method, for instance, that does not want to catch the exception on it's own has to declare that the exception which then has to be catched from the caller of the method by default - if not, the compiler will not compile the code. This is a very controversial issue within the (Java-) community because the need to catch checked exceptions naturally leads to more programming overhead. But again, the compiler tells you that the programmer of the method wanted you to explicitely respect that this kind of exception(s) may occur - and you have to deal with it. Integration might be tough, but at least you know about the possible exceptions without consulting the documentation simply by compiling your code. I, personally, had my difficulties accepting this feature, but at least the advantages had beaten the "programming verbosity" pants off for me and I think you will love this feature as it follows your way in larger projects.
-
-
29 May 07
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.