468,107 Members | 1,434 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,107 developers. It's quick & easy.

Bjarne's comments about exception specification

200 100+
Hello everyone,


How do you understand the Bjarne's comments about exception specification? Especially, "not required to be checked across compilation-unit" and "violations will not be caught at run time"?

section 14.6.1 Checking Exception Specifications

--------------------
Importantly, exception-specifications are not required to be checked exactly across compilation-unit boundaries. Naturally, an implementation could check. However, for many large and long-lived systems, it is important that the implementation does not -- or, if it does, than it carefully gives hard errors only where violations will not be caught at run time.
--------------------


thanks in advance,
George
Jan 20 '08 #1
8 1101
weaknessforcats
9,207 Expert Mod 8TB
The exception specification only appears in the function prototype. If you compile source file A with the function prototype, file B containing the code for the function is not checked to see if the function violates the exception specification. The check just cannot be made since files are compiled one at a time.

You need to have the function prototype in the file with the function definition for the check to occur.

The check is a compile-time check. At run time all you have is the bits, there's no code to check against.
Jan 20 '08 #2
George2
200 100+
Hi weaknessforcats,


I do not agree with you that checking only current compile unit will make us miss anything about exception specification contract conformation. :-)

Suppose in current compile unit if we need another function from another compile unit, yes, compiler could only check the declaration of the imported function from another compile unit.

But, when compiler compiles the exact another compile unit which contains the implementation of the function, it should check whether the declaration conforms to the implementation according to the contract of exception specification. Right? So, nothing is missed and integrity is ensured. :-)

[quote=weaknessforcats]The exception specification only appears in the function prototype. If you compile source file A with the function prototype, file B containing the code for the function is not checked to see if the function violates the exception specification. The check just cannot be made since files are compiled one at a time.[quote]


regards,
George
Jan 22 '08 #3
weaknessforcats
9,207 Expert Mod 8TB
George2, you can only check the current compile unit. There is no provision in a build for looking inside other source files.

Therefore, whatever is in the function prototype is assumed correct.

Heck, you could have different prototypes in different files that throw different exceptions and a function that throws something else entirely. There's no way to check.

The only check that can be made is in the file containing the function. There, the throw could be checked against the function prototype.
Jan 22 '08 #4
George2
200 100+
No weaknessforcats!


I think the compiler can check. Maybe I have not made myself understood. Here is a more detailed sample to show my points,

1. Suppose in compile unit foo.c, we use goo.h, which contains function goo's declaration which indicates it throws GOOException;

2. When compiler compiles foo.c, it simply trust goo function throws GOOException;

3. When compile compiles goo.c, which contains the real implementation of goo function, the compiler can check whether goo function truly follows the contract to throw GOOException or not.

The key point is (3) which you missed my points, so you can see compiler never missed anything, agree?

Please feel free to correct me if I am wrong.

George2, you can only check the current compile unit. There is no provision in a build for looking inside other source files.

Therefore, whatever is in the function prototype is assumed correct.

Heck, you could have different prototypes in different files that throw different exceptions and a function that throws something else entirely. There's no way to check.

The only check that can be made is in the file containing the function. There, the throw could be checked against the function prototype.

regards,
George
Jan 23 '08 #5
weaknessforcats
9,207 Expert Mod 8TB
No weaknessforcats!


I think the compiler can check. Maybe I have not made myself understood. Here is a more detailed sample to show my points,

1. Suppose in compile unit foo.c, we use goo.h, which contains function goo's declaration which indicates it throws GOOException;

2. When compiler compiles foo.c, it simply trust goo function throws GOOException;

3. When compile compiles goo.c, which contains the real implementation of goo function, the compiler can check whether goo function truly follows the contract to throw GOOException or not.

The key point is (3) which you missed my points, so you can see compiler never missed anything, agree?
Nope.

Expand|Select|Wrap|Line Numbers
  1. //goo.c
  2. void funct()
  3. {
  4.     throw 5;
  5. }
  6.  
Expand|Select|Wrap|Line Numbers
  1. //foo.c
  2. void func() throw (GOOException);      
  3.  
  4. int main()
  5. {
  6.      func();
  7. }  
  8.  
Here func throws an int. The compiler is told that func throws only a GooException. When compiling foo.c no check is made in goo.c for thje real throw.

Heck, it may not be goo.c. func() could be in a third party library and all you have are the bits.

There is simply no way to check.
Jan 23 '08 #6
George2
200 100+
Thanks weaknessforcats,


I agree and understand your below point now. All we are talking about is obnly a part of what Bjarne's points -- "Importantly, exception-specifications are not required to be checked exactly across compilation-unit boundaries.".

Now, I am interested in how you understand the other part -- "However, for many large and long-lived systems, it is important that the implementation does not -- or, if it does, than it carefully gives hard errors only where violations will not be caught at run time."?

I have quoted again the comments from Bjarne below.

section 14.6.1 Checking Exception Specifications

--------------------
Importantly, exception-specifications are not required to be checked exactly across compilation-unit boundaries. Naturally, an implementation could check. However, for many large and long-lived systems, it is important that the implementation does not -- or, if it does, than it carefully gives hard errors only where violations will not be caught at run time.
--------------------

Nope.

Expand|Select|Wrap|Line Numbers
  1. //goo.c
  2. void funct()
  3. {
  4.     throw 5;
  5. }
  6.  
Expand|Select|Wrap|Line Numbers
  1. //foo.c
  2. void func() throw (GOOException);      
  3.  
  4. int main()
  5. {
  6.      func();
  7. }  
  8.  
Here func throws an int. The compiler is told that func throws only a GooException. When compiling foo.c no check is made in goo.c for thje real throw.

Heck, it may not be goo.c. func() could be in a third party library and all you have are the bits.

There is simply no way to check.

regards,
George
Jan 25 '08 #7
weaknessforcats
9,207 Expert Mod 8TB
Importantly, exception-specifications are not required to be checked exactly across compilation-unit boundaries.
This means your exception specification in the function prototype does not need to be checked against the actual function.

Naturally, an implementation could check.
He says it's OK of some adventurous compiler writer wants to do this. But it is not required by the language.

it is important that the implementation does not -- or, if it does, than it carefully gives hard errors only where violations will not be caught at run time.
He says, if your compiler does this check that it better produce errors at compile time so the program does not produce unexpected excpetions at run time. That is, if the error will be caught at run time, then it would not be a compile time error.

for many large and long-lived systems, it is important that the implementation does not
That is, if it was compiling an running OK before, then it shouel be allowed to do so. No one will go into an existing major application and make code changes to appease some fervent compiler writer.

He says to let the sleeping dogs lie.

Means that an existing application that has been compiling abd running OK better not start getting a bunch of compile time errors as a result of this check.
That is, if it was compiling an running OK before, then it shouel be allowed to do so. No one will go into an existing major application and make code changes to appease some fervent compiler writer.

He says to let the sleeping dogs lie.
Jan 25 '08 #8
George2
200 100+
Thanks weaknessforcats,


My question is answered.

This means your exception specification in the function prototype does not need to be checked against the actual function.



He says it's OK of some adventurous compiler writer wants to do this. But it is not required by the language.



He says, if your compiler does this check that it better produce errors at compile time so the program does not produce unexpected excpetions at run time. That is, if the error will be caught at run time, then it would not be a compile time error.


That is, if it was compiling an running OK before, then it shouel be allowed to do so. No one will go into an existing major application and make code changes to appease some fervent compiler writer.

He says to let the sleeping dogs lie.

Means that an existing application that has been compiling abd running OK better not start getting a bunch of compile time errors as a result of this check.
That is, if it was compiling an running OK before, then it shouel be allowed to do so. No one will go into an existing major application and make code changes to appease some fervent compiler writer.

He says to let the sleeping dogs lie.

regards,
George
Jan 27 '08 #9

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

12 posts views Thread by Ritz, Bruno | last post: by
17 posts views Thread by Bryan Bullard | last post: by
2 posts views Thread by Paul Drummond | last post: by
6 posts views Thread by benben | last post: by
13 posts views Thread by junw2000 | last post: by
4 posts views Thread by George2 | last post: by
4 posts views Thread by amphetaman | last post: by
1 post views Thread by Solo | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.