|
Thanks Maxwell,
I have read again the chapter and Bjarne only mentioned, "there is no way to catch exceptions from the initialization of global variables (section 14.7)".
No words like local or global catch. Do you have the book at hand?
regards,
George
|
|
|
|
|
George_George wrote: No words like local or global catch.
Please look it up in Cambridge Dictionary for the definitions of "local" and "global"!
Maxwell Chen
|
|
|
|
|
Thanks Maxwell,
I have taken time to type down all the original words here,
--------------------
This will catch every exception, except those thrown by construction and destruction of global variables. There is no way of catching exceptions thrown during initialization of global variables. The only way of gaining control in case of throw from an initializer of a nonlocal static object is set_unexpected ($14.6.2). This is another reason to avoid global variable whenever possible.
--------------------
You can see there is no terms like local or global.
regards,
George
|
|
|
|
|
Then what do you think about "... catching exceptions thrown from global variables"?
Maxwell Chen
|
|
|
|
|
Thanks Maxwell,
My understanding is catching exceptions from initialization (constructor) of global variables. Since the whole sentence is "There is no way of catching exceptions thrown during initialization of global variables".
Anything wrong?
regards,
George
|
|
|
|
|
George_George wrote: "there is no way to catch exceptions from the initialization of global variables (section 14.7)"
Well, for instance, I've not the book at hand, but I'm able to tell "from the initialization" from "inside the initialization".
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Hi CPallini,
I have taken time to type down all the original words here,
--------------------
This will catch every exception, except those thrown by construction and destruction of global variables. There is no way of catching exceptions thrown during initialization of global variables. The only way of gaining control in case of throw from an initializer of a nonlocal static object is set_unexpected ($14.6.2). This is another reason to avoid global variable whenever possible.
--------------------
Any comments after reading this and reviewing my code sample above?
regards,
George
|
|
|
|
|
George_George wrote: This will catch every exception, except those thrown by construction and destruction of global variables. There is no way of catching exceptions thrown during initialization of global variables. The only way of gaining control in case of throw from an initializer of a nonlocal static object is set_unexpected ($14.6.2). This is another reason to avoid global variable whenever possible.
Please mind that the subject (the 1st word, "This") is the below.
int main()
try {
}
catch(std::range_error) {
}
catch(std::bad_alloc) {
}
catch(...) {
}
Maxwell Chen
|
|
|
|
|
Sure, Maxwell!
In your above approach, in main there is no way of catching exceptions from constructor of global variables.
But, it does not mean there is no way to catch exceptions from constructor of global variables, like I showed above -- besides the method of catching in main as you showed above. Agree?
regards,
George
|
|
|
|
|
On that page, Stroustrup is not talking about catching exceptions inside a ctor or dtor, okay?! For that kind of approach, it is noted in another section.
Maxwell Chen
|
|
|
|
|
George_George wrote: Any comments after reading this and reviewing my code sample above?
Yes, the reported original words confirm my observation: if a constructor throws and then catches itself, outside of the construction process you see nothing, hence Bjarne obviously refers to exceptions thrown by global object constructors AND not catched inside the constructors themselves.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
We should ask Chris to add a new emoticon: one where there is a head banging on a wall...
|
|
|
|
|
Hi Cedric,
If you have any confusions, please share with us.
1. I do not think I am always correct. And I am happy to learn from you and correct myself.
2. I do not think Bjarne is always correct -- at least from literal point of view.
regards,
George
|
|
|
|
|
George, I suggest you to attend some English class.
Maxwell Chen
|
|
|
|
|
From commucating with you guys, I improved my English.
regards,
George
|
|
|
|
|
... (I refuse to speak in English.)
Maxwell Chen
|
|
|
|
|
George_George wrote: I do not think I am always correct
But you need a very big amount of argumentations to give up.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Definitely.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
No CPallini,
1.
CPallini wrote: Yes, the reported original words confirm my observation: if a constructor throws and then catches itself, outside of the construction process you see nothing,
We can do anything as we like to do in exception handler, like write log.
2.
CPallini wrote: hence Bjarne obviously refers to exceptions thrown by global object constructors AND not catched inside the constructors themselves.
If it were his point, I have no further question. But my original understanding is, there is no way to catch exceptions from constructor of global variables -- not the limitatino of catching exceptions in main.
regards,
George
|
|
|
|
|
George_George wrote: We can do anything as we like to do in exception handler, like write log.
Yes we you can. But this is NOT the point.
We cannot impose to all people that develop classes for us to write logs. I mean Bjarne refers (probably) to a generic scenario: you haven't control to internal details of the global object you're instancing hence, if it simply throws, you have no chance to catch thrown exception.
George_George wrote: But my original understanding is, there is no way to catch exceptions from constructor of global variables -- not the limitatino of catching exceptions in main.
Your original understanding is probably wrong (on statistical grounds too ).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Thanks CPallini,
It makes more senses. You mean we can not access the code of constructor of the class of the global variable and in its constructor, it is not written in a way that constructor can handle the exception by itself by throw outside?
CPallini wrote: you haven't control to internal details of the global object you're instancing hence
regards,
George
|
|
|
|
|
I mean the general scenario is:
You're using an object whose constructor may throw (to the outside world!) or not and you cannot (or don't want or whatever...) change its constructor internal details.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Thanks CPallini,
I agree. Your reply is one of the most great replies in this discussion.
regards,
George
|
|
|
|
|
The original layout of that page is below.
...... For example:
int main()
try {
}
catch(std::range_error) {
}
catch(std::bad_alloc) {
}
catch(...) {
}
This will catch every exceptions, except those thrown
by ctor or dtor of global variables.
Maxwell Chen
|
|
|
|
|
Hi Maxwell,
If this were Bjarne's point, I will have no question. But as I showed to you, there is ways to catch exception from constructor of global variable -- so to say "there is no way of catching exceptions thrown from initialization of a nonlocal static object".
regards,
George
|
|
|
|