Not Authorized errors don't seem to be caught inside requestLocation

[phrz]

I have to figure out how to handle the CoreLocation errors thrown when I call CLLocationManager.requestLocation, because I am not able to use PromiseKit's .catch to catch them. Namely, kCLErrorDomain error 1 (a permission error) is not capable of being handled via PromiseKit catching.

Moreover, it's very hard to chain CLLocationManager.requestAuthorization with CLLocationManager.requestLocation because the former is a Guarantee, which leads to really bad ambiguity problems (according to the compiler) when I try to use .then and call .requestLocation, as one may expect to do when using this library in the real world.

I believe it would be best for requestAuthorization to be a Promise rather than a Guarantee, and fail when authorization is not achieved. Alternatively, to avoid breaking this existing method, this could be implemented in a similarly named function. For requestLocation to not enable developers to handle CoreLocation errors through PromiseKit seems like a significant problem — one should be able to catch authorization errors, etc.

[mxcl]

I have to figure out how to handle the CoreLocation errors thrown when I call CLLocationManager.requestLocation, because I am not able to use PromiseKit's .catch to catch them. Namely, kCLErrorDomain error 1 (a permission error) is not capable of being handled via PromiseKit catching.

Apple itself don't provide this error. PromiseKit only can surface errors that Apple provide.

Moreover, it's very hard to chain CLLocationManager.requestAuthorization with CLLocationManager.requestLocation because the former is a Guarantee, which leads to really bad ambiguity problems (according to the compiler) when I try to use .then and call .requestLocation, as one may expect to do when using this library in the real world.

Our requestLocation also handles requestAuthorization for you automatically, so you don't have to chain them. FFR chaining a guarantee and a promise works, you just have to specify the return types, this is detailed multiple times in our Troubleshooting guide.

I believe it would be best for requestAuthorization to be a Promise rather than a Guarantee, and fail when authorization is not achieved.

As said, Apple don't error for this, so we cannot either.

Thanks. LMK if you have any other questions.

[phrz]

Is it possible for the promise functions to somehow tie into CLLocationManagerDelegate, which is capable of handling errors from the authorization and location finding processes? It may be more ergonomic for users.

Sent from my iPhone

On Apr 4, 2018, at 09:08, Max Howell notifications@github.com wrote:

I have to figure out how to handle the CoreLocation errors thrown when I call CLLocationManager.requestLocation, because I am not able to use PromiseKit's .catch to catch them. Namely, kCLErrorDomain error 1 (a permission error) is not capable of being handled via PromiseKit catching.

Apple itself don't provide this error. PromiseKit only can surface errors that Apple provide.

Moreover, it's very hard to chain CLLocationManager.requestAuthorization with CLLocationManager.requestLocation because the former is a Guarantee, which leads to really bad ambiguity problems (according to the compiler) when I try to use .then and call .requestLocation, as one may expect to do when using this library in the real world.

Our requestLocation also handles requestAuthorization for you automatically, so you don't have to chain them. FFR chaining a guarantee and a promise is as simple as: Promise(guarantee).

I believe it would be best for requestAuthorization to be a Promise rather than a Guarantee, and fail when authorization is not achieved.

As said, Apple don't error for this, so we cannot either.

Thanks. LMK if you have any other questions.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mxcl]

Is it possible for the promise functions to somehow tie into CLLocationManagerDelegate, which is capable of handling errors from the authorization and location finding processes?

It does, and last time someone opened this same ticket we discovered that these errors are not reported by Apple to the delegate. Apple merely logs them.

[mxcl]

Actually you're talking about CLError.denied, my bad.

I'm pretty sure this is sent to catch. There is no reason I can see it would not. Can you provide your code sample that fails?

[phrz]

I'll have to look back in my repo history for the culprit, I can get back to you this weekend.

[mxcl]

PMK itself now errors with its own notAuthorized error for this case.