Home/ Questions/Q 7177371
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T16:41:58+00:00

I need to write C++ API, which consists of several exported C++ classes exposed

  • 0

I need to write C++ API, which consists of several exported C++ classes exposed from Dll, using .lib files (MSVC). From the answer to my another question I understand, that exported class methods cannot use exceptions, in the case if C++ API is built in one VC++ version (let’s say 2010), and client code is written in another VC++ version. Since exceptions cannot be a part of public API interface, I am looking for another error handling strategy. My restrictions: I don’t want to use COM, and rich error code system (like HRESULT) is not enough for me. I want to have exception-like class which contains error code, error message and any other information that I need. Also, I don’t want to make separate build for every VC++ version.

My current approach is the following. Every public class method returns enumerated value (like ErrorCode). In the case the method fails, static function like GetLastErrorInfo returns the pointer to C++ class (let’s say ErrorInfo), which contains reach error information. ErrorInfo is kept as thread-specific data, and contains error information from the last call in the current thread. If last API call succeeded, GetErrorInfo returns NULL.

Consider this code with exceptions:

try
{
    classPtr->DoSomething();
    cout << classPtr->GetData() << endl;
}
catch(const MyException& ex)
{
    cout << ex.GetErrorMessage() << endl;
    return;
}

Without exceptions, it looks like this:

ErrorCode result;
int data;
result = classPtr->DoSomething();
if ( result != Success )
{
    cout << MyClass::GetLastErrorInfo()->GetErrorMessage() << endl;
    return;
}
result = classPtr->GetData(data);
if ( result != Success )
{
    cout << MyClass::GetLastErrorInfo()->GetErrorMessage() << endl;
    return;
}
cout << data << endl;

This doesn’t look good. Class interface is messy: every function now has ErrorCode return type. Return values become output parameters. Is there better approach, that allows to have reach error information, and to keep clean public API interface?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You are possibly overlooking a simple solution. The only restriction is that an exception cannot cross a module boundary. There is no problem with the client code itself throwing an exception. So provide an inline function in the header, say CheckReturn(), that throws the rich exception.

    For inspiration, look at the COM IErrorInfo interface and its associated _com_error class. They solve the exact same problem. Also note the #import directive available in MSVC, it auto-generates the small wrapper functions that make the call and throw the exception on a failure return value. But you don’t want to use COM so that’s not directly usable.

    • 0