There was one call to a throwing function inside
`checkArticles(in:correspondToStreamItemsIn:)` which was not
appropriately marked with `try`. Add that keyword, and then bubble out
the chain of errors through additional layers of helpers to the
enclosing test:
* This `checkArticles` variant was called by two others
* …one of which was used in `testAddNewFeedSuccess()`
* …another of which was used in various `verify` sync helpers
* …which were referenced from `testSyncing()`, a test case method
None of these involved any particular async hoops to jump through, and
since the top-level callers were all test functions, we can count on
XCTest to handle any errors thrown — no additional `catch` or handling
on our part is necessary.
Two more cases of completion blocks taking Results, requiring a
do/catch/Result.get() to unwrap.
This commit deliberately leaves one build error for a more comprehensive
fix, since it occurs in a helper function that will have broader
fallout.
Most fetch completion blocks took a parameter that was expected to be
some result data type, but is now a Result. Rename these parameters;
wrap their existing bodies in do/catch blocks; and recreate the original
underlying variable using the result of `Result.get()`.
Prepend a few synchronous calls that started throwing with `try` along
the way.
Add `error` parameters to completion blocks which now pass them. Assert
these errors are always nil in the existing tests.
Flip calls to `selectPendingCount()` so they are async, with a
completion block that asserts about the results instead of asserting
about the return value. Since the closure takes a Result, unwrap it in a
do/catch block at each site; `XCTAssertNoThrow` doesn't help us bubble a
value out from `Result.get()`, and I'd rather not use `try!` here. There
might be a stylistic discussion to be had about this unwrapping, though.
