Error Handling

< BACK  NEXT >

[oR]

In the code shown so far in this chapter, errors trapped by the smart pointer wrapper functions have resulted in _com_issue_errorex being called. This has displayed the HRESULT generated by the offending call. The problem, though, is that some of the smart pointer wrapper functions attempt to continue execution and use invalid interface pointers. For example, here is the wrapper function for Connection::Execute:

 inline _RecordsetPtr _Connection::Execute (        _bstr_t CommandText,        VARIANT * RecordsAffected, long Options ) {   struct _Recordset * _result;   HRESULT _hr = raw_Execute(CommandText,       RecordsAffected, Options, &_result);   if (FAILED(_hr))     _com_issue_errorex(_hr, this, __uuidof(this));   return _RecordsetPtr(_result, false); } 

You can see that a _RecordsetPtr is created from _result even if an error was detected and _com_issue_errorex is called. Any code you have after calling Execute will probably not be executed, as this will generate a memory exception fault. One solution is to call the raw_ versions of the functions (like raw_Execute in the above code), since these will always return HRESULT values to your code. You will then need to create the smart pointer class objects (such as _RecordsetPtr) from the interface pointers (such as Recordset).

Another solution is to use exception handling. Unfortunately, you cannot use C++ exception handling since it is not supported on Windows CE. Consequently, you will need to deal with Win32 Structured Exception Handling (SEH). This is a large topic, and the examples shown here are simple and only show rudimentary use of SEH.

First, you will need to raise an error in the function _com_issue_errorex. Calling the Windows CE function RaiseException does this. The first argument is the error code, and in this case the HRESULT value that caused the problem is used. The other parameters concern flags and passing additional exception information, and these are not used here.

 void _com_issue_errorex(HRESULT hr, IUnknown* pUnkn,       REFIID riid) {   RaiseException(hr, 0, 0, NULL); } 

Next, you will need to trap the exception in your code using "__try" and "__except" blocks. In Listing 16.14 a connection is made, and then an obviously bad SQL statement is executed through that connection in a __try block. This will result in _com_issue_errorex being executed and an exception being generated. Execution will jump to the __except block. The error code is obtained using the GetExceptionCode Windows CE function. This must be executed in brackets following the __except statement. The HRESULT is then displayed to the user. Note that the code following the __except statement (the Close connection) will be executed, so the connection will be closed cleanly. Without the exception handling, the connection would be left open. This can cause problems for subsequent database access calls.

Listing 16.14 Structured exception handling

 void Listing16_14() {   AdoNS::_ConnectionPtr pConnection;   HRESULT hr;   EXCEPTION_RECORD ExceptionRecord;   if(!GetConnection(pConnection))       return;   _bstr_t bStrSQL(_T("BAD SQL Command"));   __try   {     ExecuteSQL(pConnection, bStrSQL);   }   __except (hr = GetExceptionCode(),         EXCEPTION_EXECUTE_HANDLER)   {     cout  _T("Trapped Failure: ")  hr  endl;   }   pConnection->Close();   cout  _T("Finished")  endl; } 

During the course of your ADOCE and ADOXCE programming exploits, you will encounter many different HRESULT errors. These can either be returned from ADO or ADOXCE, or from the OLEDB provider for the database you are using. I suggest you search the MSDN Library that is shipped with Microsoft Visual Studio (rather than Microsoft eMbedded Visual C++) for the error number. You are likely to find a description of the error there.

< BACK  NEXT >