-
Notifications
You must be signed in to change notification settings - Fork 136
iOS: request error does not reject plugin call #224
Comments
Hmmmm. I reported #230. This would probably resolve the dns name failure (I hope)? Wonder if it would catch the timeout issue as well. I'm gonna try applying this and see. |
Sweet! It looks like this handles the timeout issue as well. I'm gonna apply this patch locally. |
Even with this patch, the error object returned doesn't have much info. It looks like:
When I do the logging in the swift file it looks like it has the "timeout" and "bad endpoint" errors, but they don't get propagated up. I wonder if this is true of all the errors being rejected in the swift code. |
mrahn24 - your fix does not seem to properly return the error information to the reject function. That function always receives the object { code: "REQUEST", error: "", errorMessage: "error", message: "error" } which provides no information about the actual error. Instead, the function request should call something like call.reject(e.localizedDescription, "Http Request") which returns the object (in this case for a timeout) { code: "Http Request", error: "", errorMessage: "The request timed out", message: "The request timed out" } On an editorial note, I'm surprised that this plugin made it into the community pool without the most rudimentary checking of error handling. Another very basic defect exists with basic error handling as I noted in #232. That is actually a defect in Capacitor.fromNative |
Hey there, thank you @funkyvisions @nickredding for your comments regarding the rejected error object. I had implemented this differently before, but then decided to adapt to the behavior in the other functions, since I don't know the exact reason why the errors are rejected like this and like to have a consistent behavior, even if it's not the best. 😉
|
mrahn24 I don't understand why you prefer call.reject("Error", "REQUEST", error, [:]) over call.reject(error.localizedDescription, "Http Request") since the latter provides more error information than just "error". Note that the error object in your fix doesn't make it to the Javascript layer (error ends up as just an empty string) so there is no other way for the client code to get the error description. If your pull request is to be merged I think you should update it to provide error.localizedDescription |
I am also experiencing the posted issue. I tested the changes of #225 locally and it does solve the error catching.
I suggest using |
I’ve dumped this in favor of cordova-plugin-advanced-http by using awesome-cordova-plugins. It’s amazing how many of these Capacitor core plugins are broken or lacking functionality. |
* fix: Fixed missing request plugin call rejection * refactor: Adjusted error messages to provide better information
@nickredding Thank you again for your comment! I don't "prefer" the way the errors are currently handled, but I did it that way, because I don't know why the current error handlers were implemented as they are and what the maintainer's intention was by doing it that way. I agree with you that the current error handling provides no real information to the JS layer, so I've updated the PR. Hope that this will solve your concerns as well. Have a great day! |
Describe the bug
When a request error occurs, e.g. the device has no internet connection, the plugin call does not getting rejected. As a result the error can not be handled by ionic.
To Reproduce
Steps to reproduce the behavior:
=> The error does not get catched
Expected behavior
The plugin call rejects and the error does get catched
Smartphone (please complete the following information):
Additional context
The text was updated successfully, but these errors were encountered: