# Handling Error Information

Keep in mind that it is legal to return a status code only from the implementation of an interface method sanctioned as legally returnable. Failure to observe this rule invites the possibility of conflict between returned error code values and those sanctioned by the application. In particular, pay attention to this potential problem when propagating error codes from internally-called functions.

Applications that call interfaces should treat any unknown returned error code (as opposed to a success code) as synonymous with E_UNEXPECTED. This practice of handling unknown error codes is required by clients of the OLE-defined interfaces and APIs. Because typical programming practice is to handle a few specific error codes in detail and treat the rest generically, this requirement of handling unexpected or unknown error codes is easily met.

The following code sample shows the recommended way of handling unknown errors:

    HRESULT hrErr;
    hrErr = xxMethod();

    switch (GetScode(hrErr))  {
        case NOERROR:
          //success
          break;

        case x1:
          .
          .
          break;

        case x2:
          .
          .
          break;

        case E_UNEXPECTED:
        default:
          //general failure
          break;
    }

The following error check is often used with those routines that don’t return anything special (other than S_OK or some unexpected error):

    if (xxMethod() == NOERROR)
        //success
    else
        //general failure;