9.1 Exceptions in Convert.ToDouble
The static methods in the static class System.Convert are able to convert values of one type to values of another type.
Consult the documentation of System.Convert.ToDouble. There are several overloads of this method. Which exceptions can occur by converting a string to a double?
Write a program which triggers these exceptions.
Finally, supply handlers of the exceptions. The handlers should report the problem on standard output, rethrow the exception, and then continue.
If you consult the documentation of the method ToDouble in class System.Format you will find out that ToDouble may throw a FormatException or an OverflowException.
The following program demonstrates the throwing and pseudo-handling of the exceptions FormatExceptions and OverflowException, as triggered by using System.Format.ToDouble on strings.
In order to provoke an OverflowException you must type very many ciffers before the decimal point (more than 300). You can also provide a string such as "1,8E308". Recall that the the minimum and maximum doubles are -1,79769313486232E+308 and 1,79769313486232E+308 respectively.
Due to the rethrowing, the output of the program only reveals the FormatException. The reason is that FormatException will lead to a program halt, and therefore we never come to the conversion of the long string with lots of fives. If you - against all recommendations - eliminate the rethrowing you can observe the OverflowException as well.
9.2 Exceptions in class Stack
In the lecture about inheritance we specialized the abstract class Stack.
Now introduce exception handling in your non-abstract specialization of Stack. I suggest that you refine your own solution to the previous exercise. It is also possible to refine my solution.
More specifically, introduce one or more stack-related exception classes. The slide page "Raising and throwing exceptions in C#" tells you how to do it. Make sure to specialize the appropriate pre-existing exception class!
Arrange that Push on a full stack and that Pop/Top on an empty stack throw one of the new exceptions. Also, in the abstract stack class, make sure that ToggleTop throws an exception if the stack is empty, or if the stack only contains a single element.
Finally, in a sample client program such as this one, handle the exceptions that are thrown. In this exercises it is sufficient to report the errors on standard output.
We introduce a StackUnderflowException and a StackOverflowException together with the abstract class. Notice that the method ToggleTop throws the StackUnderflowException if the stack has less than two elements.
Here follows the refined non-abstract specialization of class Stack, which includes exception handling:
The following client triggers the requested exception handling:
Notice, in this client class, that the first encountered stack error causes termination of Main. There is no notion of 'returning back to' or 'retrying' the offending stack operation. This may not always be satisfactory.
9.3 More exceptions in class Stack
In continuation of the previous exercise, we now wish to introduce the following somewhat unconventional handling of stack exceptions:
With these ideas, most stack programs will be able to terminate normally (run to the end).
I suggest that you introduce yet another specialization of the stack class, which specializes Push, Pop, and Top. The specialized stack operations should handle relevant stack-related exceptions, and delegate the real work to its superclass. Thus, in the specialized stack class, each stack operation, such as Push, you should embed base.push(el) in a try-catch control structure, which repairs the stack - as suggested above - in the catch clause.
Here is the additional stack specialization called HStack (for Handling Stack), in which exception handling occurs in the immediate neighborhood of each Push, Pop, and Top operation:
The class AStack (standing for ArrayStack), which is the base-class of HStack, corresponds to the solution of the previous exercise. We assume that instance variables of AStack are protected.
Notice that the version of HStack above discards the top part of the stack in case of a StackOverflowException. This is probably not what we want in a real application. It is a good exercise to remove the other half part of the stack. For this purpose, consider a new Stack operation which pops the stack in the opposite end of pushing. With such a stack, we approach a queue datatype.
Here is a sample client program, which in itself "handles" stack exceptions that remain unhandled:
The output of the program is as follows:
9.4 Revealing the propagation of exceptions
The program output does not, however, reveal that the chain is followed in reverse order in an attempt to find an appropriate exception handler.
Revise the program with handlers in M, N, and P that touch the exception without actually handling it. The handlers should reveal, on standard output, that P, N, and M are passed in an attempt to locate a relevant exception handler. Rethrow the exception in each case. See here how this can be done.
Here is my solution:
Notice the use of catch without specifying the type or name of the exception.
The output of the program is here:
Generated: Monday February 7, 2011, 12:19:03