Timeline for How to deal with HRESULT spaghetti?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 22, 2021 at 11:47 | comment | added | Stack Exchange Broke The Law | Note that your context information is a bit inefficient because you are constructing the string on every call, even the ones that don't fail. You could avoid this by passing a lambda that returns the context information. | |
| Sep 21, 2021 at 19:40 | comment | added | Bondolin | Indeed, I commend this practice. I think I may have miscommunicated. I understand there to be, on a per-API basis, two sets of HRESULT errors: those communicating exceptional behavior, and those merely indicating some kind of successful but negative result that would not be regarded an error per se. The former I would wrap with exceptions, as you have said; the latter would be those I wrap with a mapping to my own domain-specific code, to encapsulate away the aspect of dealing with an HRESULT. | |
| Sep 21, 2021 at 11:51 | comment | added | zett42 | @Bondolin In code that adds another abstraction level (i. e. is not just a thin wrapper for an existing API), I catch exceptions from lower abstraction levels, create a new exception that is specific to my API and wrap the catched exception as a nested exception. This way users of my library are able to handle errors on a higher level but there is no loss of information compared to transforming HRESULT to a domain-specific code. | |
| Sep 20, 2021 at 16:01 | comment | added | Bondolin | Thanks for the helpful answer. Would also like to add to it's no longer an exception and the error code should be returned normally - at the risk of being pedantic, in the spirit of good encapsulation, it may also be a good idea to wrap this aspect as well by mapping the HRESULT code to a corresponding domain-specific code. But that is entirely up to the design. | |
| Oct 8, 2017 at 14:35 | vote | accept | vlind | ||
| Jun 11, 2017 at 0:29 | history | edited | zett42 | CC BY-SA 3.0 | added hint for deriving from std::system_error |
| Jun 11, 2017 at 0:21 | history | edited | zett42 | CC BY-SA 3.0 | link to SO |
| Jun 11, 2017 at 0:13 | review | First posts | |||
| Jul 11, 2017 at 0:17 | |||||
| Jun 11, 2017 at 0:12 | history | answered | zett42 | CC BY-SA 3.0 |