fix(apple): actually show user-friendly alert messages#8282
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
jamilbk
force-pushed
the
fix/actually-alert-error-type
branch
from
7e3745c to
a754d84
Compare
| @MainActor | ||
| struct macOSAlert { // swiftlint:disable:this type_name | ||
| static func show(for error: Error) { | ||
| let message = (error as UserFriendlyError).userMessage() ?? "\(error)" |
There was a problem hiding this comment.
So this means try to cast and if cast fails, fallback to printing the raw error?
Would it be better to define the parameter of the function to enforce at compile-time that it needs to implement the UserFriendlyError protocol? That seems more robust because you'll get a compile error any time you want to show an alert for something that doesn't implement the protocol.
There was a problem hiding this comment.
Well we need this to handle any error. Since we bubble up errors from external frameworks through here, we won't know in advance what they can be.
We picked a couple error types to make friendlier here because they are likely to happen if the user doesn't enable permissions.
There was a problem hiding this comment.
And? Just implement the protocol for these errors. Or make a separate function that shows a generic error.
The type-system is trying to help you here by flagging all the parts of the code where you are not displaying a user-friendly error dialog.
There was a problem hiding this comment.
We don't know what errors could be raised. Ther's potentially dozens or hundreds from the various calls from the various frameworks we use.
There was a problem hiding this comment.
Or is the issue that when catching the errors, we don't know their type?
There was a problem hiding this comment.
Ah, I see what you mean - implement the protocol for Error and NSError?
There was a problem hiding this comment.
Correct we don't know in advance what error types are caught
There was a problem hiding this comment.
We don't know what errors could be raised. Ther's potentially dozens or hundreds from the various calls from the various frameworks we use.
Ah I thought that upon catch, the compiler enumerates what errors it may through but I guess it doesn't?
There was a problem hiding this comment.
Ah, I see what you mean - implement the protocol for
ErrorandNSError?
That is also an option yeah. What I am planning to do in the Rust GUI client is: Show a generic error like "Oh, we've encountered an expected error. If this persists, contact your administrator." but log the detailed error to Sentry.
2 participants
Before, we would receive an
NSErrorobject and the type-matching wouldn't take effect at all, causing the default alert to show every time. This solves that by introducing aUserFriendlyErrorprotocol which is more robust against the two mainErrorandNSErrorvariants.