Why does my program using cstring work while the one from the book doesn't?

[Jarvis323]

Here is a somewhat cleaner version of the same diagram. Light blue is showing what happens if an exception is NOT thrown (normal return). I think in the book they could have left those arrows out, since it's more or less obvious. The red arrows show what happens when the exceptions are thrown.

I think you misread the blue arrows as if they are red arrows?

But yes, the diagram is pretty terrible (correct but terrible), so I don't blame you if you want to find a new book.

 

[yungman]

I think the diagram is just a confusing diagram because of the clutter.

It says "Normal return" at the end of fun1(){} with an arrow that goes to after fun1(); is called. That means if an exception is NOT thrown, it goes there. The other arrow, says exception can be handled here, points directly from fun1() throw to the catch block.

This is the same as your program shows and as the book says, it's just easy to misread the diagram.

I am saying the diagram on the right is correct, it's the writing on the page is incorrect.

 

[Jarvis323]

I am saying the diagram on the right is correct, it's the writing on the page is incorrect.

On the image you seemed to indicate it was wrong.

The writing is correct too I think. Maybe it's also just confusing language? What did you think was wrong about it exactly? Anyways, the writing was trying to explain what is shown in the diagram I posted. So if you understand that, you've got it and can move on. If the book you're using is too confusing, then maybe move on and try C++ primer.

 

[yungman]

On the image you seemed to indicate it was wrong.

The writing is correct too I think. Maybe it's also just confusing language? What did you think was wrong about it exactly? Anyways, the writing was trying to explain what is shown in the diagram I posted. So if you understand that, you've got it and can move on. If the book you're using is too confusing, then maybe move on and try C++ primer.

This is a larger copy and I put red lines. I wrote how I read it. The diagram is correct as proven already, the writing is wrong.

It said the throw is not caught in fun3() ( because fun3() doesn't have a catch block), it will pass to the calling function fun1() ( also don't have a catch block) and should pass back to the one that called fun1() which is the Try block.

From fig.15.3 and both your program and my program, it jumped directly from fun2()( I called fun2() as fun3() in Fig.15.3) to the catch block.

I work with VS enough, if the function passes back to fun1(), it will step from fun3() to fun1() for sure. It did not.

 

[Jarvis323]

This is a larger copy and I put red lines. I wrote how I read it. The diagram is correct as proven already, the writing is wrong.

It said the throw is not caught in fun3() ( because fun3() doesn't not have a catch block), it will pass to the calling function fun1() ( also don't have a catch block) and should pass back to the one that called fun1() which is the Try block.

From fig.15.3 and both your program and my program, it jumped directly from fun2()( I called fun2() as fun3() in Fig.15.3) to the catch block.

Yeah, you just didn't understand. It IS CORRECT! LOL

 

[yungman]

Yeah, you just didn't understand. It IS CORRECT! LOL

Like how? That's how I read it. Tell me how you read it.

 

[Jarvis323]

Like how?

It isn't saying how the control flow goes. It is explaining the propagation of the exception. Imagine the exception is like a baseball and it is flying past the next lines of code (which aren't being executed) yet, waiting to be caught. It is saying the ball does't just hit a wall at the end of a function, it keeps flying forward until eventually it is caught (then the control flow will go there where it is caught), or if nothing catches it, then program will terminate. The exception propagating doesn't mean the code it is skipping is executing.

 

[yungman]

It isn't saying how the control flow goes. It is explaining the propagation of the exception. Imagine the exception is like a baseball and it is flying past the next lines of code (which aren't being executed yet, waiting to be caught). It is saying the ball does just hit a wall at the end of a function, it keeps flying forward until eventually it is caught (then the control flow will go there), or if nothing catches it, then program will terminate.

No it said it will pass back to the calling function. Like I said, I step through a lot of programs, if it pass through, VS will stop at the calling function even if it stop at the line with the last "}". VS do this every time. It never skip that.

If the book said it will go directly to the catch, then I have no problem with it.

 

[Jarvis323]

No it said it will pass back to the calling function. Like I said, I step through a lot of programs, if it pass through, VS will stop at the calling program even if it stop a the line with the last "}". VS do this every time. It never skip that.

If the book said it will go directly to the catch, then I have no problem with it.

You just didn't understand it. There's nothing at all more to it than that.

 

[yungman]

You just didn't understand it. There's nothing at all more to it than that.

Sorry, I disagree. Like I said, I stepped through a lot of programs that call functions, even the function doesn't return anything, it will step back to the calling function after it finished.

 

[Jarvis323]

Sorry, I disagree. Like I said, I stepped through a lot of programs that call functions, even the function doesn't return anything, it will step back to the calling function after it finished.

You still obviously don't understand what it was attempting to convey. You can try reading it again, and read my comments, and if you still cannot understand it, just accept you don't get it, and try learning some other way.

 

[yungman]

You still obviously don't understand what it was attempting to convey. What more is there to say. You can try reading it again, and read my comments, and if you still cannot understand, just accept you don't get it, and try learning some other way.

"An exception that is thrown but not caught within a function may be passed on to the calling function the next level up". This means if the exception is not caught in fun3(), it will passed on to the calling function fun1().

"Exception thrown by fun3() when it is called by fun1(). There is no try block in fun1(), so exceptions thrown by fun3() will be passed to the function that called fun1()." This means exactly what I said above. fun1() doesn't have a catch block either, so the exception is passed from fun1() back to try block.

Tell me which part do I not understand, please enlighten me.

 

[Jarvis323]

"An exception that is thrown but not caught within a function may be passed on to the calling function the next level up". This means if the exception is not caught in fun3(), it will passed on to the calling function fun1().

"Exception thrown by fun3() when it is called by fun1(). There is no try block in fun1(), so exceptions thrown by fun3() will be passed to the function that called fun1()." This means exactly what I said above.

Which part do I not understand, please enlighten me.

You're not understanding what the book was trying to explain. You're conflating the author's explanation of the propagation of the exception, with control flow.

 

[yungman]

Well agree to disagree. I am very exact as this is science.

This is actually like break, where you drop everything and just jump to the destination.

 

[Jarvis323]

Well agree to disagree. I am very exact as this is science.

Maybe you can email the author and ask what he meant, and accuse him of making an error, and argue with him about if he is wrong or if you are wrong? I'm just trying to help.

 

[yungman]

Maybe you can email the author and ask what he meant, and argue with him about if he is wrong or if you are wrong? I'm just trying to help.

I think I'll wait for the new book I just ordered suggested by jbunniii .

Actually while I was stuck with that, I when back to Gaddis, actually after the first few pages, I followed right along and finished about 20 pages last night. So I am back to Gaddis again. I am almost finish with the exception, using class and all that. It is not that hard, Gaddis never talked about the process, only Ivor made a big sting how it jumps, so I want to make sure I follow right along. Now I see from everyone here confirming it jump all the way over to catch, it's not even a question anymore.

Anyway, thanks for your time, I apologize if I came out too strong. We both agree it fly over directly to the catch block, it's just how the book described. Too many books around to bother to write to the author. I don't enjoy wasting time to prove I am right or not. I just want to make sure I understand correctly, there is not any double we all agree about the program.

Thanks

 

[Jarvis323]

Well agree to disagree. I am very exact as this is science.

This is actually like break, where you drop everything and just jump to the destination.

It's really confusing, as you are very unclear about what you think is wrong. But here is what I think I understand.

The book says the exception gets passed to the calling function if it's not caught in the function it's thrown from. And if it's not caught in the calling function, then it is passed to the next level (the calling function of the calling function, and so on). If it is never caught, then the program terminates.

It seems you thought the exception being passed along means the code is being executed or something (or the code is going where he describes the exception going). That is not the case.

The diagram agrees with the writing and that agrees with what your program does. Your misunderstanding is again confusing the authors description of the propagation of the exception with the execution of lines of code.

 

[yungman]

No, I don't mean when passing back to fun1(), meaning it has to execute something in fun1. It's like if fun1 call fun3, things got pushed onto stack( I don't mean your kind of stack, I mean stack pointer in processor to store the return address etc.). fun3 can just "stop" by fun1 to pop the stack pointer and fun1 back to try just to pop the stack pointer. Nothing is executed. So when the book describe like that, I expect the step will land back to fun1 and then to try even it doesn't execute any program lines. VS is very good in showing these steps even though no code is being executed.

What happens is it's literally calling a "BREAK" that you DROPPED everything and jump to catch block directly. This is what we agree on, not the normal way of returning back from a function that involves popping stacks. The way the book described, it's like step by step return back, not a fly ball flying over everything. In my low level assembly programming days, this is a very important distinction as direct jump is very different. I don't know how high level language handle the stack pointer, not popping the stack is dangerous.

 

[yungman]

Unless of cause VS doesn't not show the temporary stop in this program. i don't know enough to see one way or the other. Maybe Mark44 who is the expert on VS can jump in. It is just my experience the VS is very good in jumping back to the calling function, even if it just landed on the empty closing bracket of the very last line of code "}". It just "stop by" for one stop!

 

[Jarvis323]

No, I don't mean when passing back to fun1(), meaning it has to execute something in fun1. It's like if fun1 call fun3, things got pushed onto stack( I don't mean your kind of stack, I mean stack pointer in processor to store the return address etc.). fun3 can just "stop" by fun1 to pop the stack pointer and fun1 back to try just to pop the stack pointer. Nothing is executed. So when the book describe like that, I expect the step will land back to fun1 and then to try even it doesn't execute any program lines. VS is very good in showing these steps even though no code is being executed.

What happens is it's literally calling a "BREAK" that you DROPPED everything and jump to catch block directly. This is what we agree on, not the normal way of returning back from a function that involves popping stacks. The way the book described, it's like step by step return back, not a fly ball flying over everything. In my low level assembly programming days, this is a very important distinction as direct jump is very different. I don't know how high level language handle the stack pointer, not popping the stack is dangerous.

I think you've got this wrong as well. This relates to the other thing (left side
of your image) you thought the book got wrong. That's why I posted code to demonstrate that the call stack is "popped" before the catch block.

Also, the stack we talk about in C++ is the same one you're talking about in assembly.

 

[pbuk]

@yungman yet again you are being pig-headed and insisting that only you are right and everybody else is wrong. I can see that, @Mark44 @Vanadium 50 @Jarvis323 @jtbell can see it, many other people reading this thread can see it but you cannot.

In the vain hope that reinforcement will 'enlighten' you, once more: the book does not say that control flow returns to fun1(). It says that "exceptions thrown by fun3() will be passed to the function that called fun1()".

I work with VS enough, if the function passes back to fun1(), it will step from fun3() to fun1() for sure. It did not.

VS follows control flow so yes, if control flow was passed back to fun1 then you would see it step back into fun1. But nobody is asserting that control flow is passed back to fun1.

Well agree to disagree. I am very exact as this is science.

You are exactly wrong and you need to understand and accept this.

 

[pbuk]

Here's an exercise in interpretation:

A train ticket that is bought on Tuesday but not used before midnight may be used on Wednesday. If it is not used on Wednesday it can be used the day after.

Does this say that the ticket was used on Wednesday?

 

[yungman]

Here's an exercise in interpretation:

A train ticket that is bought on Tuesday but not used before midnight may be used on Wednesday. If it is not used on Wednesday it can be used the day after.

Does this say that the ticket was used on Wednesday?

That said your writing is really bad, just like the book. If that's what you try to say, I would just say:

You can buy the ticket and USE it ANY DAY. Instead of going in circle to confuse people.

The book is NOT inventing anything, the point of the book is to make it very clear and easy to read and the book failed. All it has to say is fun3 will bypass everything and go straight to catch block. We won't be wasting time debate this.

 

[Jarvis323]

Here is some code you can use to check what happens with the stack.

#include<iostream>
#include<string>
using namespace std;

struct A
{
    std::string name;
    A( const std::string & _name ) : name( _name ) {}
    ~A() {
        cout << "destroying " << name << endl;
    }
};

struct E
{
    E() {}
    E( const E & other ) {
        cout << "copy constructor E" << endl;
    }
};

void fun2( int b )
{
    A a2( "a2" );
    if (b > 2) throw E();
}
void fun1(int a)
{
    A a1( "a1" );
    fun2(a);
}

int main()
{ 
    int x = 5;

    try
    {
        A a0( "a0" );
        fun1( x );
        cout << "You entered: " << x << "\n\n";
    }
    catch( E e )
    {
        cout << "Out of range.\n\n";
    }
 
    cout << "Program ends.\n\n";
 
    return 0;
}

destroying a2
destroying a1
destroying a0
copy constructor E
Out of range.

 

[yungman]

Ok, this is regarding the page on the left side. The books said very clearly as red lined. See attachment

"Throwing an exception leaves the try block immediately, so at that point all the automatic objects that have been defined within the try block prior to the exception being thrown are destroyed".

Then: "It's also the reason why the exception object is copied in the throw process."

In order to be able to copy the exception object into temp, it has to by copied BEFORE destruction..

Look at fig. 15.2, It's is not clear what the number 1, 2, 3, 4 and 5 in the rectangular blocks stands for. Looked to be the order of events that is going to happen. So the event has to be:
1)Throw. which is labeled as 1 in fig. 15.2
2) Copy. which is labeled as 4 in fig 15.2.
3) destroy. which is labeled as 2.
4) Find first handler with a parameter type matching... labeled 3 and should start with catch(Type1 ex).
5)end.

So the writing is NOT the same as in Fig. 15.2.This is very important for people that is trying to learn. You go into detail, you cannot afford to make mistake.

Before you guys start calling me racist, I am Chinese from Hong Kong before AND I have lousy English. I think a lot of people in programming are minority and not good in English. BUT this is not an excuse to write a book with confusing description. When I was trying to publish papers in American Institute of Physics, my company actually got a technical writer to proof read my papers, made corrections and let me proof read before summited. This is NOT your own notes, this is for people to read and understand. Particular books, you are NOT publishing a new idea, the whole point of a book is to convey the information clearly to people that tries to learn. There is no innovation, no novel ideas, the only task is to explain clearly to people existing information. those people should know their limits and get a technical writer to proof read before publishing. There is no excuse for this.

I might be new in programming, but I am no stranger in studying books. I have 3 tall bookshelves of textbooks on physics, math, electronics, specialties books like Firewire, USB etal books that I studied, a lot of them from cover to cover through the years. I know how a good written book should be. I have more books in the subjects than the Stanford U library.
PS: Sorry the copy looks so awful, it is still drying and all wrinkled.
Look at my poor books, one chapter is cpt16 of Gaddis, the other is cpt 15 of Ivor.

 

[Mark44]

It is just my experience the VS is very good in jumping back to the calling function

But your experience doesn't include working with exceptions, which can change the normal flow of control -- that's what they're supposed to do.

Again, and repeating what I said before and referring to the code in post #20, after the user enters a value out of range, such as 3, this is what happens.

1. fun1() is called in main's try block.
2. fun2() is called in fun1().
3. fun2() throws an exception.
4. The catch block prints " Out of range."
5. The line right after the catch block prints " Program ends."
6. The last line of the program executes.

Control does not return to fun1(), the function that called fun2(), so the normal flow of control is disrupted.
Control also does not return to the line right after the call to fun1() -- the program never prints " You entered."

You can verify the above by putting break points in select places, and noting that the break points don't get hit.

 

[yungman]

But your experience doesn't include working with exceptions, which can change the normal flow of control -- that's what they're supposed to do.

Again, and repeating what I said before and referring to the code in post #20, after the user enters a value out of range, such as 3, this is what happens.

1. fun1() is called in main's try block.
2. fun2() is called in fun1().
3. fun2() throws an exception.
4. The catch block prints " Out of range."
5. The line right after the catch block prints " Program ends."
6. The last line of the program executes.

Control does not return to fun1(), the function that called fun2(), so the normal flow of control is disrupted.
Control also does not return to the line right after the call to fun1() -- the program never prints " You entered."

You can verify the above by putting break points in select places, and noting that the break points don't get hit.

I agree, I was saying the book is wrong in the writing. The fig 15.3 is absolutely correct.

In another words, what the book wrote in English is wrong. The fig 15.3 is absolutely correct as proven by my program tracking where the program goes step by step.

The throw in fun3() jumped straight to the catch block. Never gone through fun1() and try block at all. We all agree on that already.

 

[yungman]

I am pretty much done with the exception part of the chapter of Gaddis. It is really quite simple. I can see Ivor book go deeper into nested of try, calling function with try-throw-catch inside function and all that.

Gaddis just talked a little about Rethrowing an Exception and don't even have an exercise program for it. The last one is handling bad_alloc for new operator that has a very small exercise program.

My question is whether learning what Gaddis covered is enough for exception? Here is the example of the most difficult program in Gaddis on exception. I actually put everything I learn in Gaddis into this program so you can see what Gaddis covered in the chapter:

#include <iostream>
using namespace std;
class Rectangle
{private: double width, length;
public:
    class NegativeW//exception class for -ve width
    { private:   int wid;
     public:
         NegativeW(int w) {wid = w;}
         int getW() const {return wid;}
    };
    class NegativeL//exception class for -ve length
    {private:     int len;
     public:
        NegativeL(int l) {len = l;}
        int getL() const {return len;}
    };
    Rectangle() //default constructor
    {   width = 0.0; length = 0.0;    }
    void setWidth(double w)
    {    if (w >= 0) width = w;
        else throw NegativeW(w);
    }
    void setLength(double len)
    {    if (len >= 0) length = len;
        else throw NegativeL(len);
    }
    double getWidth() const
        { return width;}
    double getLength() const
        { return length;}
    double getArea() const
        {return (width*length);}
};
int main()
{    double width, length;
    bool tryAgain = true;
    Rectangle myRect;
    cout<<" Enter the rectangle width: "; cin>>width; cout<<"\n";
    while(tryAgain)
    {
        try
        {    myRect.setWidth(width);//call Rectangle object myRect.setWidth()
            tryAgain = false;    //if width is +ve, set tryAgain = false to jump out
        }
        catch (const Rectangle::NegativeW negW)//argument is NegativeW object negL
        {    cout<<" You entered "<<negW.getW()<<" Enter +ve number: ";//re-enter a width
            cin>>width;
        }
    }//end while loop

    cout<<"\n Enter the rectangle length: ";
    cin>>length; cout<<"\n";
    tryAgain = true;//set to keep looping
    while(tryAgain)
    {
        try
        {    myRect.setLength(length);//call Rectangle object myRect.setWidth()
            tryAgain = false;//if length is +ve, set tryAgain = false to jump out
        }
        catch (const Rectangle::NegativeL negL)//argument is NegativeL object negL
        {    cout<<" You entered "<<negL.getL()<<" Enter +ve number: ";//re-enter a width
            cin>>length;
        }
    }//end while loop
    cout<<" The area of rectangle is: "<<myRect.getArea()<<"\n\n";
}

1) I put multiple exception using class object as exception object.
2) Using exception Handler to recover from errors ( ask to enter the right number over again)
3) Extract data from exception class(print out what was the input)

I am surprise that's all Gaddis covered in detail, I expect it would be more difficult. If this is enough, then I want to move on. Let me know what extra stuffs do I need to learn in the topic of Exception. Of cause, it's never enough, I just want a reasonable stopping point.

Next stop will be Template.

Thanks

 

[Jarvis323]

Ok, this is regarding the page on the left side. The books said very clearly as red lined. See attachment

"Throwing an exception leaves the try block immediately, so at that point all the automatic objects that have been defined within the try block prior to the exception being thrown are destroyed".

Then: "It's also the reason why the exception object is copied in the throw process."

In order to be able to copy the exception object into temp, it has to by copied BEFORE destruction..

Look at fig. 15.2, It's is not clear what the number 1, 2, 3, 4 and 5 in the rectangular blocks stands for. Looked to be the order of events that is going to happen. So the event has to be:
1)Throw. which is labeled as 1 in fig. 15.2
2) Copy. which is labeled as 4 in fig 15.2.
3) destroy. which is labeled as 2.
4) Find first handler with a parameter type matching... labeled 3 and should start with catch(Type1 ex).
5)end.

So the writing is NOT the same as in Fig. 15.2.This is very important for people that is trying to learn. You go into detail, you cannot afford to make mistake.

Before you guys start calling me racist, I am Chinese from Hong Kong before AND I have lousy English. I think a lot of people in programming are minority and not good in English. BUT this is not an excuse to write a book with confusing description. When I was trying to publish papers in American Institute of Physics, my company actually got a technical writer to proof read my papers, made corrections and let me proof read before summited. This is NOT your own notes, this is for people to read and understand. Particular books, you are NOT publishing a new idea, the whole point of a book is to convey the information clearly to people that tries to learn. There is no innovation, no novel ideas, the only task is to explain clearly to people existing information. those people should know their limits and get a technical writer to proof read before publishing. There is no excuse for this.

I might be new in programming, but I am no stranger in studying books. I have 3 tall bookshelves of textbooks on physics, math, electronics, specialties books like Firewire, USB etal books that I studied, a lot of them from cover to cover through the years. I know how a good written book should be. I have more books in the subjects than the Stanford U library.
PS: Sorry the copy looks so awful, it is still drying and all wrinkled.
Look at my poor books, one chapter is cpt16 of Gaddis, the other is cpt 15 of Ivor.
View attachment 276699

Did you not run my code and see that it shows that the writing was exactly correct, word for word, precisely? The order is as the author says it is, NOT the way you naively assumed it must be. You have a major problem understanding written language and concepts (no matter how clearly it's written), don't blame it on the authors.

 

[yungman]

Did you not run my code and see that it shows that the writing was exactly correct, word for word, precisely? The order is as the author says it is, NOT the way you naively assumed it must be. You have a major problem understanding written language and concepts (no matter how clearly it's written), don't blame it on the authors.

No! This is NOT about the program. It's about what is written doesn't match the figure. I am fine with whatever way is correct, it CANNOT be both correct.

I asked you how do you interpret the book if you don't agree, please don't call me naive. There's only very few sentences in the book that is relevant, READ every single one of them.

Tell me sentence by sentence what did I read wrong.

 

[Jarvis323]

No! This is NOT about the program. It's about what is written doesn't match the figure. I am fine with whatever way is correct, it CANNOT be both correct.

I asked you how do you interpret the book if you don't agree, please don't call me naive. There's only very few sentences, READ every single one of them.

What is written does match the text.

And yes, your insistence that the order the author says things happen in is wrong is very naive. It's also astounding that you're still claiming it's not correct when it's been demonstrated that YOU are WRONG, NOT the author.

 

[yungman]

What is written does match the text.

And yes, your insistence that the order the author says things happen in is wrong is very naive. It's also astounding that you're still claiming it's not correct when it's been demonstrated that YOU are WRONG, NOT the author.

NO, I SAID WHAT THE BOOK SAID DOES NOT MATCH IT'S OWN DRAWINGS. DON'T YOU EVEN READ? Just like the page on the right side.

Whether your program agree one way or the other is irrelevant.

 

[Jarvis323]

NO, I SAID WHAT THE BOOK SAID DOES NOT MATCH IT'S OWN DRAWINGS. DON'T YOU EVEN READ?

And you are WRONG. They do match. I did read it. And yes they match.

 

[yungman]

And you are WRONG. They do match. I did read it. And yes they match.

Explain, how. You can start with the page on the right side. EXPLAIN how the writing match the fig 15.3.

 

[Jarvis323]

Explain, how. You can start with the page on the right side. EXPLAIN how the writing match the fig 15.3.

First of all, we were arguing about your naivety in assuming that figure 15.2 is wrong. Your comments on the page are wrong. The order the author gives is correct, and his writing matches the figure.

Second, we already went back and forth about your misunderstanding of the writing and of figure 15.3. Again you were WRONG. You pass the blame for your own inability to understand onto the author. You must just accept you're just flat WRONG and fix your understanding. You've got a lot to learn about humility.