Picture of standard C++ exceptions
[ exceptions2.png ]
Project 3 due in
Assigned Work Due -- One Question on Chapter 16
Why doesn't exeption work
You forgot the spelling "exception". C++ requires well spelled words.
Chapter 16 pages 812 -- Try Catch
In order to make sure that all possible errors are handled without causing the program to terminate, is it possible to enclose the entire program in a try catch block?
Yes -- you can put all the code inside a try block and catch anything that is thrown out -- [ catcher.cpp ] but this does not stop the program from terminating. To do that you need to place the try...catch deeper inside the code -- inside a loop probably.
It is better to THINK.
Chapter 16 pages 818-819 -- Exceptions
how does the program keep running even though it found an error (even if it was an infrequent error)?
C++ programs tend to ignore things that go wrong.... they do an operation that produces garbage, and they continue to process garbage.... and output it.
We had an old joke that if you tell a computer to take a long walk on a short pier you here a splash.
Programs that fail to detect and handle errors and mistakes tend to continue and produce rubbish answers. Some times for years.
The story of the two "Atlas" compilers in the 1960's.
Chapter 16 pages -- Exceptions
Why do we use exceptions?
The purpose of "throw" in C++ is to protect statements from having to process bad data.
Chapter 16 pages 818-840 -- Exception Handling
How would one go about using Exception handling when they're not sure of the type of error that will occur or where it will be?
Your first job in every program is to spot the things that could go wrong and protect the code from reacting badly.
Exception handling is a useful tool.... but first you have to practice what I call the Power of Negative Thinking to spot things like negative square roots, arrays with unchecked indexes, pointers that might be NULL, files that haven't been opened, data that doesn't fit the plan.
A programmer has combine extreme optimism with extreme pessimism. Write code optimistically, and add exceptions pessimistically.
The optimist says the glass is half full.....the pessimistic programmer says it is full of bugs!
Chapter 16 pages 827-828 -- try and catch
can you please go more into detail about how "try" and "catch" works.
Demonstration on the board or in class. Chalk may be thrown.
Chapter 16 pages 819 -- Exception Handling Examples
Can you give us an example of exception handling through code?
Can you give an example of an exception within a program that does not occur every time the program is run?
Can you also give an example of how to handle such an exception?
Program that sometimes throws an exception [ except.cpp ]
A more complex example: [ 09t.cpp ]
Exercise: what does it do.... use a pencil and paper! How might you change it so that it does not throw an exception when it is run?
Chapter 16 pages 821 -- Performance
Does Exception-Handling greatly reduce the speed of the program?
No.
Exception handling typically happens as the program skids to a halt and before it crashes.... after most of the computation is done.
Think of a cartoon where the villain chases another character over the cliff. The villain does not slow down until the look down.... and then it is too late.
Chapter 16 pages 822-823 -- Exception Handling
what happens if an exception is thrown outside a try block?
I don't know. Two possibilities: compiler complains or lizards come out of your nose.
Chapter 16 pages 822-823 -- try Block
Could you explain what a try Block does?
It is a piece of code where exceptions are handled in a particular way. The "catches" at the end of the block define how they are handled.
Inside a try-block you may find another one. This redefines the actions.... and so on.
Chapter 16 pages 825-826 -- Exception Handling
When will it be acceptable to use exception handling?
Use "try", "throw" and "catch" from now on.
Use in any program where a bad thing can happen -- divide by zero, subscript or index out of range, removing data from an empty vector, putting 11 numbers in an array of 11 vectors, inputting a string when a number was needed, ....
A "throw e" chould be done as close to where the error is detected as possible.
The "try{......}catch (E)..." for the thrown "e" at just the right level. Where the error can be diagnosed and perhaps corrected.
Chapter 16 pages 825-826 -- Exception Handling
Why do we use exception handling?
To handle unplanned for data simply.
Chapter 16 pages 826 -- Exceptions
The book says that exceptions are not for asynchronous things
but could you you define asynchronous in this case?
Things that happen to the program from outside or out of its control.
I'm not sure that I agree with this classification -- I find it a little academic and unclear.
I think it is most important to make the code as clear as possible. And if throwing an exception does that -- do it.
Chapter 16 pages 826 -- exception handling
When I throw an object, how many times will it be copied?
I figure -- each throw may lead to an object being created. However if the "catch" specifies "pass by reference" (and it should!) then it won't be copied when it is caught.
Notice -- if the catch leads to the same object being thrown then another copy might be made...
In practice this is not very important.
Chapter 16 pages 826 - 827 -- Rethrowing an Exception
Should every 'try' block have a 'throw' statement? If not, how do you know when to code for a throw statement and when not to?
No. You often put a try block in a main program:
int main()
{
try{
...
} catch (...)
{ cerr << "Unexpected object thown\n";
}
}[ catcher.cpp ]
Then you can happily add "if(....)thow ....;" anywhere something might go wrong.
Chapter 16 pages 828 -- Exception Specifications
Can you give out an example of exception specification and how does it work?
An execution specification is added to the header of a function and lists the exceptions that the function can throw. Every exception that it can throw must be listed.
So
T f(data) ....can throw anything.
T f(data) throw()....can throw nothing.
T f(data) throw(logic_error)....can only throw logic_errors.
Chapter 16 pages 828 -- Exception Specifications
What is the functions of the parameter list in a exception specification?
It lists the types of things that the function might throw.
Unlisted types of object, can not be thrown -- the compiler will object if it thinks this can happen. But more typically a special "unexpected" function is called.
Chapter 16 pages 829-830 -- Stack Unwinding
Could you better explain figure 16.4?
Demo on Board.
Chapter 16 pages 829-830 -- Stack Unwinding
When the function in which the exception was not caught terminates, why do all local variables in that function get destroyed?
Functions always remove their local variables when they return normally. The function replaces them with the value that is returned by the function (if any). It recycles the memory, ready for other functions to use. It works well with how expressions are evaluated -- data is put on a stack, operators remove the top ones and replace them by the result of the operation. It also supports recursion. It is a rule that we have used in computing since the early 1960's.
The interesting thing is that throwing an exception out of a function (not catching it locally) also removes the variables.
Chapter 16 pages 830 -- stack unwinding
How many times will the program unwind the stack to find a catch handler before the program is terminated?
Until it runs out of stack -- even the main program -- and then dies.
Chapter 16 pages 835 -- nothrow
whats the significance of nothrow?
When you #include <new> you redefine the "new" operator. You modernize it to use exceptions.... but perhaps you want to temporarily return to the old-fashioned for for one or two occasions..... so you use a special version of new that include "new(nothrow)".
As usual C++ gives you lots of options to shoot your self in the foot.
I'm not putting the modern version of new in any quizzes or the final.
Chapter 16 pages 835 -- <cstdlib>
The book suggests using an abort or exit function within the c standard library; what is the difference between these two functions?
The 'exit(int i)' terminates the program and returns the value of i to the operating system.
The 'abort(...)' function makes the program fail -- error messages -- as well as terminating it.
Chapter 16 pages 836 -- auto_ptr Function
When is auto_ptr ever useful? Can you give an example?
This is a new feature. Not one I have had much experience of. But it looks like a good way to worry less.
You mostly need it when you have a program can grab a large amount of memory and also can exit abnormally without calling the normal deletion routine. This means the memory can not be reused. It is garbage. It is as if the memory has leaked out of the program. By using
auto_ptr< Type > apt = new (Type(...));rather than
Type *pt = new (Type(...));you can be certain sure that the memory allocated to whatever apt points at will be recycled properly.
With pt you have to think about all the things that can happen and plan to delete the storage.
I believe that something simple as second assigned value
pt=new T(....);without previously doing delete pt will create a memory leak. I think that apt will do the delete for you...
I'm not planning to take auto_ptr any further in this course. Check out [ Auto_ptr ] (wikipedia) if you need to use one.
Chapter 16 pages 839 -- Exception hierarchy
Is the UML diagram just scratching the surface on the amount of error that can occur, or is that pretty much all of them?
It shows all the standard C++ exception types.
You can add as many as you like, anywhere in the hierarchy.... or anywhere else.
Personally -- real programmers plug their new types of exceptions somewhere into this hierarchy so that their code can be understood.
. . . . . . . . . ( end of section CSci202 Computer Science II, Session 12 Exceptions) <<Contents | End>>
Lab 06
[ lab06.html ]
Next -- File Handling
[ 13.html ]