Implementaton of error handling for xlang#361
Conversation
manodasanW
requested review from
BenJKuhn,
DefaultRyan,
Scottj1s,
devhawk and
kennykerr
…ng_type_load to indiciate class not found scenarios.
…into mawign/error_abi
…sing xlang_type_load to indiciate class not found scenarios." This reverts commit 3a42c3d.
| inline constexpr xlang_result xlang_error_untranslatable_string{ static_cast<int32_t>(0x80070459) }; | ||
| inline constexpr xlang_result xlang_error_class_not_available{ static_cast<int32_t>(0x80040111) }; | ||
| inline constexpr int32_t xlang_hresult_no_interface{ static_cast<int32_t>(0x80004002) }; | ||
| #endif |
There was a problem hiding this comment.
I understand that we need E_NOINTERFACE for QI, for interop scenarios. But it's a bit confusing that we also have xlang_no_interface. What prevents a QI impl from returning that? Maybe QI should be strongly typed with a com_interop_result enum that contains two values, including this one?
Also, in what scenario would I then use xlang_no_interface?
There was a problem hiding this comment.
The stance I was thinking of taking is the return value of QueryInterface isn't a xlang error (which would be xlang_error_info*), but rather a convention documented for that function (similar to the return values of AddRef/Release). If the caller of QueryInterface decides that the value they recieved from it is something they consider an error / unexpected, they can then generate an xlang error for it. In the case, QueryInterface returns the hresult version of no interface and that is determined by the caller to be an error in their case, they would originate an xlang error with the error as xlang_result::no_interface.
There was a problem hiding this comment.
I am going to complete this PR, but I do want to continue this conversation to determine whether my stance is the right model and whether it would be clear to a developer implementing QueryInterface or whether it should be changed to something as you mentioned or something else.
|
|
||
| private: | ||
| xlang_result m_result{}; | ||
| xlang_string m_message{ nullptr }; |
There was a problem hiding this comment.
Are these handle types? If so, where is the destructor that releases them?
There was a problem hiding this comment.
Good catch, I will have a PR to address this and your other comment.
|
|
||
| void GetMessage(xlang_string* message) noexcept override | ||
| { | ||
| *message = m_message; |
There was a problem hiding this comment.
Shouldn't these be calling the equivalent of WindowsDuplicateString?
4 participants
This change defines the xlang error codes and implements the error origination API and the error info interface exposed in the xlang PAL. Existing code have been updated to use them.