-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Storage functions return different error types #13071
Comments
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight. |
Just for fun (and also because I'm using it in my app), I tested the same thing but with |
Thanks for the report. We have a bit of mess from trying to balance transitioning to Swift and maintaining backwards compatibility. We'll see if we can make some improvements in our upcoming major release update. |
Makes sense, thanks! Separately, is Firebase 11 SDK expected to include more |
@edonv We don't have near-term plans for more |
Description
I've found that different Storage functions return different error types. By this I mean that one action failing throws an
NSError
while a different one throws aStorageError
.I've tested this at least on the
async
functions, but they seem to use the same logic under the hood as the Combine and plain callback versions. Here are the things I tested:reference.getMetadata()
throws aStorageError
.StorageError.swiftConvert(objcError: error as NSError)
, which internally maps to aStorageError
from anNSError
generated by the failed call.reference.delete()
throws anNSError
.StorageErrorCode.error(withServerError: error, ref: self.reference)
, which internally maps anNSError
returned by the server call to a newNSError
with extra metadata, including the error code.The main issue here is inconsistency, making it difficult to juggle how I'm supposed to write my
catch
clause depending on the function call. I don't mind which version is used (though I'd preferStorageError
or a customError
type that contains the metadata as properties, but it should only be one. Here is how thecatch
clause differs:Reproducing the issue
No response
Firebase SDK Version
10.29.0
Xcode Version
15.4
Installation Method
Swift Package Manager
Firebase Product(s)
Storage
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved
Expand
Package.resolved
snippetIf using CocoaPods, the project's Podfile.lock
Expand
Podfile.lock
snippetReplace this line with the contents of your Podfile.lock!
The text was updated successfully, but these errors were encountered: