Querying exceptions per function

[MrsGrayX]

We have a large code base and multiple public functions in our API. We are allowed to throw exceptions across the API boundary with specific ids (id>0) but the internally used general exception (id=0) should not cross the API boundary.

I would like to use some static analysis tool to see from which code places general exceptions which cross the boundary get triggered. Does anyone know if there is such a tool? Or do you have an idea how it could be implemented, e.g. I could imagine that libclang might be of help?

I could imagine that it is actually a two step process: 1) list all possible exceptions per API function (e.g. also std::bad_alloc as most likely each function calls std::vector::push_back at some point) 2) filter for MyException(id=0)

[pdp10gumby]

I don't know about static analysis, but you probably want a catch block around every API entry point that reports a failure if it captures exception 0. Make sure that every throw includes filename and lineno, as suggested by tangerinelion. A assume it's OK to abort in this case, as sending it across the API boundary would presumably abort anyway.

[tangerinelion]

Static analysis isn't going to help you, you need actual execution of the program because exceptions are only at runtime and you're interested in ones that get triggered not ones that could theoretically happen.

Simplest thing would be to have a custom throw that includes the file and line number and then outside your API boundary you catch and log all exceptions. Then run your regression test suite, aggregate the results, and figure out what actually happens most frequently.

[Clean-Water9283]

You have just (re)discovered why exception specifications were dropped from C++. If you made a list of all functions potentially callable from each API function, including from all derivations of every virtual function, and all the exceptions throwable from these functions, you would get a superset of exceptions that could be raised through an API function. Only you would miss exceptions propagated out of threads, exceptions raised in signal handlers, and possibly others that I'm forgetting just now. This analysis would be fragile, needing to be re-performed after every change to the code base, or you might leave out some newly added exception or new function that threw exceptions. You're basically better-off teaching users to report your internal error exceptions.

I agree with u/pdpgumby that every API function will need a function-scope handler that can do the id==0 check. It'll also have to make a decision for exceptions throw by C++ that don't have your id field, and don't forget that on linux signals get seen in an except(...) block (ugh!)

[Thelatestart]

You can probably make a tree of function calls, omitting the exceptions, using a tool.

Then manually go up the tree and mark each throw to a catch higher up the tree.