The other day I found an instance that a "invalid" URL was crashing because of the
FoundationNetworking code path.
let url = URL(string: "bogus")
let data = Data(contentsOf: url)
The intention of the code in a test was actually not loading anything (
nil data), but when I upgraded to the current Foundation, I got a crash instead. This was intentional, but this might had happened because of an error in processing user input or similar. Where before we got a
nil, that the code must handle, now we are at the risk of crashing, without an easy way of checking first.
While I think that the split of
FoundationNetworking is great, maybe the current code can be improved. The above snippet is obviously not a remote URL, but it was crashing because the check is too narrow. I don't, however, know what the exact check should be.
Another detail that was a little unhelpful was finding the exact point where the
Data(contentsOf:) was being invoked. I only had the textual information of the
fatalError, which sadly was pointing to the file/line in the Foundation code. It was also not telling me about which URL have failed. The later can be easily fixed, the former would be impossible to fix unless every public API that leads to the loader code accepts file/line information, which I think would not be accepted as a PR at all.
As I say above, I'm all about the split, specially if it means that we can see a SwiftNIO backed FoundationNetworking, but I can see the pain that it causes to the ones using those initializers.