Bjarne's comments about exception specification

[George2]

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

[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.

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.

[George2]

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

[weaknessforcats]

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.

[George2]

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

[weaknessforcats]

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.

//goo.c
void funct()
{
    throw 5;
}
 

//foo.c
void func() throw (GOOException);      
 
int main()
{
     func();
}  
 

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.

[George2]

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.

//goo.c
void funct()
{
    throw 5;
}
 

//foo.c
void func() throw (GOOException);      
 
int main()
{
     func();
}  
 

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

[weaknessforcats]

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.

[George2]

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