Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Update windows error reporting #127
This cleans up the
Potential future work:
There is still one use of a local buffer that must be freed with
The calls to
This removes the need to call `StringCchPrintf` to format the string. That allows removing of the `<strsafe.h>` header import (requires WindowsXP SP2 or greater). It also allows removing the `LocalAlloc` call, and the associated pointer for the temporary string buffer.
This removes the need for one of the internal string conversions. It also makes the API a little easier to use.
At this point, a better source of documentation is the help page for the `FormatMessage` function. The documentation for `FormatMessage` is currently found at: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage
Brett208 left a comment
Changes look good. Thank you for working on cleaning this code up. My knowledge of the winapi is weak and working on it frustrates me.
Below is a screenshot of resulting error message. The %1 formatting artifact was preexisting, so feel free to merge without fixing.
I see no reason to keep the function name as an input argument. In fact that seems like a silly thing for me to have included in retrospect?
I like having the error code present. It encourages end users to lookup the error code online for more details. What if we made two versions of the function, one that returns the error code and one that does not? I wasn't sure what you were referring to using the function for in a more standardized manner so tough for me to comment more.
Feel free to merge and maybe post issues if you think it is worth it. Also happy to retest if you want to work on it more in this branch.
Eh, the function name argument was part of the original sample code that method was based on. Took me a while to even realize it wasn't that important, just part of the formatting. I initially though the function name might some sort of relevant to retrieving the actual error message. Kind of hard to know when using somewhat obscure Win API functions.
If we want to remove the parameter, we can do so in a future branch. I'll create an issue for it.
As for the "%1", I think that's related to the