aboutsummaryrefslogtreecommitdiff
path: root/COPYING
diff options
context:
space:
mode:
authornea <nea@nea.moe>2023-02-16 23:12:04 +0100
committernea <nea@nea.moe>2023-02-16 23:38:54 +0100
commitd7f875a0dc1f46402abc3462c2fbe357876773bb (patch)
tree39e9f6f4e5075ae1a70af6f20f04e8d658eff065 /COPYING
parent1d75ac44c20fafd9f834dc7c01066a85a74f89e7 (diff)
downloadNotEnoughUpdates-d7f875a0dc1f46402abc3462c2fbe357876773bb.tar.gz
NotEnoughUpdates-d7f875a0dc1f46402abc3462c2fbe357876773bb.tar.bz2
NotEnoughUpdates-d7f875a0dc1f46402abc3462c2fbe357876773bb.zip
ApiCache: Fix apparent NullPointerExceptionfix/apicache-nullpointer
`CacheResult` should in theory have either a `file != null` a `future != null` or be `disposed`. Apparently this invariant of `CacheResult` is either being violated somewhere, or the `synchronized` blocks arent as synchronized as id hoped they were. In fact, `dispose()` does not even delete the file, so i can really only see this happening because the first `synchronized` block that writes the file and the second `synchronized` block that reads from the file hold the same lock. I have no idea how this would happen, but hopefully this fixes it (since the dispose didn't have a threading issue reported so far, i feel more confident leaving the .deleteOnExit in there, but I'm also wrapping any potential IOExceptions during access, because I am just so confused how the internal state was broken.
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions