CERT C++: ERR59-CPP

This issue occurs when both of these conditions are met:

Polyspace^® assumes that library interface functions are across an execution boundary. A violation is not raised if a new operator in a library interface function raises a std::bad_alloc exception.

To use this checker correctly, specify the library interface functions in your code. Declare a function foo() as a library interface function by setting their visibility attribute. For instance:

If you do not explicitly specify a function as visible, Polyspace assumes that it is not part of a library interface.

Exception handling requires interoperability between the functions that raise the exception and the functions that handle the raised exceptions. Library functions might implement exception handling by using incompatible interfaces. For instance:

// lib.h
void foo() noexcept(false);
//lib.cpp
void foo() noexcept(false){
  //...
  throw 42;
}
//App.cpp
#include"lib.h"
int main(){
  try{
    foo();
  }catch(int& e){
    //handle exception
  }
}

Avoid raising exceptions in library interfaces. Instead of raising exceptions, return different error codes to handle unexpected situations.

#include<exception>

void __attribute__((visibility("default"))) foo(int rd) noexcept(false) { //Noncompliant
    if (rd==-1)
        throw std::exception();
}

In this example, the visibility attribute of the function foo() is set to default. Because foo() might be used in modules that have different exception handling mechanisms, exceptions raised by foo() might remain unhandled. Avoid raising exceptions from visible functions functions.

Use other methods for handling errors. For instance, set an error flag and return an error code when a logic error occurs in the code.

#include<exception>
int FLAG;

int __attribute__((visibility("default"))) foo(bool rd) noexcept(true) { 
    if (rd==-1){
		FLAG = 52;
		return -1;//Compliant
	}
}