-
Notifications
You must be signed in to change notification settings - Fork 15
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
Client-level error handling #67
Comments
Hmm, I haven't experienced the same thing. This may be because I don't have very many routes and for some of my routes I want considerably different error handling behavior. When I've written networking code using I'm not sure trying to address this at the framework level would be a good idea. I mean that literally, and not as indirect way of saying "I think this is a bad idea". My gut reaction is attempting to do so would introduce a new set of issues.
Indeed. And it'd be very problematic to only send errors to the "global" handler if it is set. Because then
I can't imagine there's any way to do that as what does it even mean to "handle the error" in any sort of deterministic sense? For example: do {
let reply = try await client.sendMessage("Get Schwifty", route: route)
<# do something with reply #>
} catch {
if case let .other(message) = error {
print("Unable to get Schwifty because: \(message)")
}
} In this example the error is being caught (not that I think we can detect that?), but only one |
You're right on the money, this is what I found challenging about this problem. Here's a few different ideas I was thinking of:
There's a few inter-related challenges:
I think one thing that makes the design of this challenging for me is my ignorance on exactly when a route handler should need to know about connection statuses (this will improve as I get more real-world experience using this framework). Retries sound like one use case that would need it. Retries would a useful (essential?) feature, but IDK what architectural layer should be responsible for implementing them. For one, if we want to support the "send, oh no the Mach service isn't installed, install it, then retry" pattern, then that would required
Any thoughts? |
Is this a pattern you're looking to do unconditionally? Because it requires user action, that's not how my code handles things. While in theory a Mach service could become uninstalled at any time, in practice it probably will never be — the far more likely scenario is it's never been installed. So checking that on first run (or the beginning of each run) is what makes sense to me. |
@amomchilov Six months later, what are your thoughts on whether client level error handling should exist? |
I'll have to think more on this. Marking unread for now, I'll come back to this when I make up my mind xD |
Closing due to inactivity. If desired, please open a new issue in the future with specific examples/use cases. |
One thing that I've noticed in my use for SecureXPC was that all my clients' callbacks followed the same pattern: they all
switch
on the result, and called a shared error handling function (in addition to some route-specific error handling).I think this might be a common use case, especially because changes to the connection state might want to be monitored, and that can happen on every call.
Adding a "global" error handler that applies across all routes of a client would be easy, but then you'd get duplicate reports of errors (once per callback, and then once again). Ideally, having a way to express "if the route callback doesn't handle the error, then give the client error handle a chance to handle it", but I don't know how we could detect if the callback handled the error or not.
Do you have any ideas for how we could improve this?
The text was updated successfully, but these errors were encountered: