Follow-up in case anyone is interested: I finally got around to refactoring my "error code" code which I asked for some input on earlier. Instead of calling it IOErrorCode I ended up with OpResult.
Follow-up in case anyone is interested: I finally got around to refactoring my "error code" code which I asked for some input on earlier. Instead of calling it IOErrorCode I ended up with OpResult.
I also added a way to make it extensible, so that it wouldn't be tied to platform error codes. I realized I needed this when integrating 3rd-party dependencies (like TLS support).
An "OpResult" basically stores an integer representing the error code or similar, and a category[1]. The actual error/result value is relative to the associated category.
The category is just a class pointer to a OpResultCategory descendant, which does all the hard work through virtual class functions (yay Delphi).
This means OpResult itself is very light-weight, yet I get all the juicy bits of OO.
OpResult has a few properties, like "Success" and "Message", as well as equality and inequality operator overloads. As mentioned these all call the category implementation which actually does the work.
For each category one can also implement a "result factory" for creating "standard" results. For example the SystemCategory has a SystemResults "factory" with class methods such as "LastError" (wraps GetLastError) and "EndOfFile".
So if you just want to know if the operation succeeded or not, one simply writes
if (not res.Success) then ...
or you can check for more specific conditions like this
if (res <> SystemResults.EndOfFile) then
res.RaiseException();
The equality test in a category may check the category of the other result, so that one can do meaningful comparisons of results from different categories.
For example TLSResults.EndOfFile would compare equal to SystemResults.EndOfFile, even though the actual error values are different (-65537 vs 38).
(the TLS stuff is work-in-progress and has not been pushed yet)
So far pretty happy with this, though might tweak it a bit.
[1]: https://github.com/lordcrc/AsyncIO/blob/master/Source/AsyncIO.OpResults.pas
I also added a way to make it extensible, so that it wouldn't be tied to platform error codes. I realized I needed this when integrating 3rd-party dependencies (like TLS support).
An "OpResult" basically stores an integer representing the error code or similar, and a category[1]. The actual error/result value is relative to the associated category.
The category is just a class pointer to a OpResultCategory descendant, which does all the hard work through virtual class functions (yay Delphi).
This means OpResult itself is very light-weight, yet I get all the juicy bits of OO.
OpResult has a few properties, like "Success" and "Message", as well as equality and inequality operator overloads. As mentioned these all call the category implementation which actually does the work.
For each category one can also implement a "result factory" for creating "standard" results. For example the SystemCategory has a SystemResults "factory" with class methods such as "LastError" (wraps GetLastError) and "EndOfFile".
So if you just want to know if the operation succeeded or not, one simply writes
if (not res.Success) then ...
or you can check for more specific conditions like this
if (res <> SystemResults.EndOfFile) then
res.RaiseException();
The equality test in a category may check the category of the other result, so that one can do meaningful comparisons of results from different categories.
For example TLSResults.EndOfFile would compare equal to SystemResults.EndOfFile, even though the actual error values are different (-65537 vs 38).
(the TLS stuff is work-in-progress and has not been pushed yet)
So far pretty happy with this, though might tweak it a bit.
[1]: https://github.com/lordcrc/AsyncIO/blob/master/Source/AsyncIO.OpResults.pas
/sub
ReplyDelete