Always use ErrorKind::NotFound for Poller::delete of unknown source#260
Conversation
|
Where I'm working today I don't have a Windows system or an Illumos/Solaris system to test this on. I relied on the CI checks to run the test I added on Windows, where it seems to have passed. It doesn't seem like there are any CI checks for either platform that uses the "Event Port" implementation and so unfortunately I've not tested the change I made to that at all. Sorry about that. 😖 Some of the CI checks have failed but I don't think the failures were caused by what I changed here. Please let me know if I'm mistaken about that! |
e6d8d9d to
d9e5a1f
Compare
|
The The FreeBSD failures are because Cirrus no longer ships the images of FreeBSD our current CI depends on. Let me update it. |
|
@apparentlymart Please rebase on master in order to fix CI issues. |
The IOCP and Event Port implementations were previously inconsistent with the others in how their "delete" implementations reacted to being asked to delete a source that wasn't previously registered with "add": they would return `Ok(())` without making any changes in that case, whereas the other implementations all return an `ErrorKind::NotFound` error. Just to improve the consistency of behavior between the implementations, those two backends will now also return ErrorKind::NotFound errors. This should not change the behavior of any correct program, but might make it easier to catch incorrect usage when testing on a system that uses one of these two backends.
d9e5a1f to
3863562
Compare
|
I've rebased it and indeed the checks all now seem to have passed. Thanks! |
The IOCP and Event Port implementations were previously inconsistent with the others in how their
deleteimplementations reacted to being asked to delete a source that wasn't previously registered withadd: they would returnOk(())without making any changes in that case, whereas the other implementations all return anErrorKind::NotFounderror.Just to improve the consistency of behavior between the implementations, those two backends will now also return
ErrorKind::NotFounderrors. This should not change the behavior of any correct program, but might make it easier to catch incorrect usage when testing on a system that uses one of these two backends.This closes #259. While writing this I realized I had incorrectly diagnosed the problem I was having as being caused by this inconsistency, but nonetheless it was still inconsistent.