¿Cómo manejar las excepciones de WinRT que resultan en Excepción?

Question

Si un tipo de tiempo de ejecución de Windows provoca un error COM .NET parece envolver este error a menudo (¿o siempre?) Solo en una instancia Exception. El mensaje de error incluye el código de error COM HRESULT. Al utilizar la nueva API criptográfica con AES-CBC, por ejemplo, una longitud de búfer incorrecta da como resultado un Exception con el mensaje "El búfer de usuario proporcionado no es válido para la operación solicitada. (Exception from HRESULT: 0x800706F8)".

Bueno, ¿cómo se supone que debemos manejar esas excepciones? ¿Deberíamos leer el código HRESULT de la excepción para tener una idea del tipo de excepción que fue? En .NET clásico obtendría un CryptographicException que podría utilizar para distinguir los errores criptográficos de otros errores.

Otra cosa que no entiendo es que las reglas de calidad del código de Microsoft indican que uno nunca debe arrojar Excepción, sino siempre los tipos derivados. La razón es que nadie debería verse obligado a detectar el Exception general que también captura más excepciones fatales como OutOfMemoryException. Otra regla dice que nunca se debe capturar Exceptio n en las bibliotecas. ¿Cómo podríamos seguir estas políticas si nos vemos obligados a atrapar Exception en las aplicaciones de la Tienda Windows o en las bibliotecas WinRT?

Por cierto: Clemens Vasters shows in his blog how we can catch Exception while avoiding to catch fatal exception. Supongo que capturar Exception ya no es un código malo.

Answer 1

Es posible detectar Exception, manejar determinados errores al encender HRESULT, y volver a lanzar el Exception si el error fue "inesperado". Por ejemplo,

try 
{ 
    // ... 
} 
catch (Exception ex) 
{ 
    switch (ex->HResult) 
    { 
    case E_INVALID_USER_BUFFER: // 0x800706f8 
     // handle invalid buffer case... 
     break; 
    default: 
     // Unexpected exception; re-throw: 
     throw; 
    } 
} 

(I desean señalar que proporciona una amortiguación inválida suena más como un error lógico que un error de ejecución, por lo que me pregunto si esta excepción en particular realmente debe ser capturado.)

Alternativamente, una una solución más general sería escribir una función o un conjunto de funciones que manejen Exception para HRESULT conocidos y vuelvan a lanzar una excepción más específica. Por ejemplo,

static void HandleKnownExceptions(Action f) 
{ 
    try 
    { 
     f(); 
    } 
    catch (Exception ex) 
    { 
     // Detect expected HRESULTs and throw the more-specific exception 
     // type for each. 
    } 
} 

Ambos enfoques funcionan igual de bien tanto en C++ como en C#.

Tenga en cuenta que no es necesariamente el caso de que Exception sea lanzado directamente por la plataforma u otros componentes. En la capa ABI de Windows Runtime, no hay excepciones: todos los errores se informan a través del límite ABI por HRESULT. El CLR traduce un puñado de HRESULT conocidos a tipos de excepción más específicos, pero no puede realizar una traducción general.