c ++测试缺少的回调函数

Question

EDIT: added backquotes to callback template. The interface was reading the asterisks as markdown indicators, not just as asterisks!

In a Windows DLL/Linux SO I am writing, I give the user app a way to register a callback function. Works great. The callback prototype looks like (void)(*callback)(void*);

I was having a fit of paranoia while writing the docs and realized, I have no really good way to know if the registered address is valid. The only feedback is either a crash or call the callback inside a try/catch.

I have no idea what exception would be thrown if the callback did not exist and who-knows-what executed. NOt even really sure that the call to "nowhere" could recover itself enough to generate the exception instead of a crash.

Yes, I know it's the user's problem. Just trying to be thoughtful and maybe help the user understand his bug.

So, what exception would this throw? Windows and Linux answers please if they differ.

Or, is there a better way to approach this without having to use an exception catch to detect the missing function?

Answer 1

There's no way to recover. Similarly, you cannot recover if the callback contains a line like *(int*)(0x1234) = 5; . Just live with it.

As a C++ library developer, you're not in the business of making sure that nothing ever crashes. You merely provide code that does what it promises when used the way you document.

Answer 2

A bit off-topic, but callbacks in the form of void(*)() , ie taking 0 arguments, are less than useful. A useful C-style callback accepts a user specified argument, so that the user can find the state corresponding to the callback. Eg:

typedef void callback_fn(void* user_arg);

callback_id register_callback(callback_fn* callback, void* user_arg);
void unregister_callback(callback_id);

Without user_arg the user of your callback will be forced to use a global variable to store state corresponding to the callback function.

Answer 3

The situation you describe is rather unlikely. I have never seen such handling anywhere. The program would just crash and ruin its user.

But your concern is valid, because the failure root cause (assigning wrong address) and its manifestation (call to invalid address) can be so far away from each other that it could be very hard to identify it.

All I could advise here is to "fail fast and loud". For instance, you could do test call of the callback whenever it is assigned. This will still lead to crash, but now in the stack trace user will see where it all started from.

Again, this is not something an ordinary library user would expect...

Answer 4

As I answered here:

How to test if an instance is corrupted? (completely different type of question, but same applies)

If the pointer is "not recognisable NULL or similar", then there is no way, in code, to tell if it's valid or not.

You also can't use try/catch to capture the failure, as "failure to execute the code" does not result in a throw.

Since this a "programmer error", I don't believe it's a big issue. Programmers can do what they like with their own code anyway, so whatever mechanism you add, it's going to be possible to circumvent in some way or another.

Answer 5

As others have said, there's no way to check, but... Is it really necessary? I'm all in favor of defensive programming, but the only way you can possibly get a pointer to a function (other than a null pointer) is by taking the address of a function. Some compilers do allow explicitly converting a pointer to an object to a pointer to function, despite the fact that the standard requires a diagnostic in such cases. But even then, the client code needs an explicit cast to screw up. And unlike objects, functions life through out the lifetime of the program, so you cannot have a problem with a dangling pointer—a pointer which was once valid, but isn't any more. There is, in fact, practically no way to get an invalid pointer to a function except intentionally (the only way that occurs to me is if the unload a DLL with the function), and if someone intentionally wants to screw up, there's no way you'll be able to prevent it.