Seeing the existence of RTTI in C++ nowadays, I had to think
"why not run time function information?" This would, for instance,
be very useful for exception handling. The traditional view of
exception handling is to let the programmer give the user several
options on catching a recoverable exception, namely:
1. Terminate this operation
2. Retry the operation
3. Reinitiate the operation
4. Continue after the place where the exception was thrown.
At present, this is not possible, as the 4th option would require the
exception handler to know exactly where the exception was thrown.
Also the 2nd and 3rd options are only partially possible.
A colleague of mine was trying to illustrate exception handling in
practice when we spotted this seeming ommission. He was trying to
write some code that would take a text file, with certain 'control'
codes (all of which were also ASCII), and convert this text file
into a Word for Windows v6.0 file. When the program hit a section in
the text file, which was marked as control code, but which wasn't a
valid control code, it threw an exception. At this point the user
should be able to, either, ignore that bit of text that the program
didn't understand, or try again (it could be that some previous
operation caused some sort of error, which is now no longer present,
so allowing a correct interpretation of the control code), or be
prompted to correct the ununderstandable control code, or tell the
program to stop the conversion.
At present, however, the only way to be able to implement all of
these options (as far as I can see) is to catch that very exception
after every single try block in the entire program, which is clearly
a complete waste of file space, as the same piece of code will be
replicated possibly hundreds of times throughout the program.
Given only one catch statement for this exception, the only things that
can be done are, termination of the process (which could waste a lot
of time.. I have seen this program take considerably over an hour for
some files), or reinitialisation of the process (again an incredible
waste of time).
The answer would clearly be to have each exception be of type pointer
to a function, or section inside a function, so that the catch
statement can return to where the exception was thrown, and continue
after the exception causing section of code. (although the latter may
have to be aided by some keyword indicating what the programmer
considers to be 'after the exception causing section of code')
Or have I missed some feature of the language that allows this?

~mysh.

--

+---------------------------------------------------------------+
| Benjamin Pflanz  | AKA: The Great God MYSH |
| B.V.Pflanz@ncl.ac.uk  | Elymas   |
| Uni of Newcastle upon Tyne |  Streak   |
| Dept. of Computing Science |     |
|---------------------------------------------------------------|
| "Behind the illusion of reality are forces that speak to me" |
|  - Jaz Coleman (of Killing Joke)    |
+---------------------------------------------------------------+