Revisit the errors thrown by library #32
Labels
enhancement
New feature or improved functionality.
Comments
lawrence-forooghian
added a commit
that referenced
this issue
Aug 29, 2024
Part of #19. References to spec are based on [1] at commit aa7455d. The @preconcurrency imports of ably-cocoa are temporary and will be removed once [2] is done; created #31 for tracking. I’ve decided to, for now, throw ably-cocoa’s ARTErrorInfo for consistency with JS; created #32 to revisit this later. [1] ably/specification#200 [2] ably/ably-cocoa#1962
lawrence-forooghian
added a commit
that referenced
this issue
Aug 29, 2024
Part of #19. References to spec are based on [1] at commit aa7455d. The @preconcurrency imports of ably-cocoa are temporary and will be removed once [2] is done; created #31 for tracking. I’ve decided to, for now, throw ably-cocoa’s ARTErrorInfo for consistency with JS; created #32 to revisit this later. [1] ably/specification#200 [2] ably/ably-cocoa#1962
lawrence-forooghian
added a commit
that referenced
this issue
Aug 29, 2024
Part of #19. References to spec are based on [1] at commit aa7455d. The @preconcurrency imports of ably-cocoa are temporary and will be removed once [2] is done; created #31 for tracking. I’ve decided to, for now, throw ably-cocoa’s ARTErrorInfo for consistency with JS; created #32 to revisit this later. [1] ably/specification#200 [2] ably/ably-cocoa#1962
lawrence-forooghian
added a commit
that referenced
this issue
Aug 29, 2024
Part of #19. References to spec are based on [1] at commit aa7455d. I’ve decided to, for now, throw ably-cocoa’s ARTErrorInfo for consistency with JS; created #32 to revisit this later. We have decided (see [3]) that we’re going to try using actors as our mechanism for concurrency-safe management of mutable state. We accept that this will lead to more of the public API needing to be annotated as `async` (as has happened to Rooms.get here), which in some cases might lead to weird-looking API, and have chosen to accept this compromise in order to get the safety checking offered to us by the compiler, and because of developers’ aversion to writing "@unchecked Sendable". We might not have needed to make this compromise if we had access to Swift 6 / iOS 18’s Mutex type, which allows for synchronous management of mutable state in a way that the compiler is happy with. But, none of the decisions here need to be final; we can see how we feel about the API as it evolves and as our knowledge of the language grows. [1] ably/specification#200 [2] ably/ably-cocoa#1962 [3] #33 (comment)
lawrence-forooghian
added a commit
that referenced
this issue
Aug 29, 2024
Part of #19. References to spec are based on [1] at commit aa7455d. I’ve decided to, for now, throw ably-cocoa’s ARTErrorInfo for consistency with JS; created #32 to revisit this later. We have decided (see [3]) that we’re going to try using actors as our mechanism for concurrency-safe management of mutable state. We accept that this will lead to more of the public API needing to be annotated as `async` (as has happened to Rooms.get here), which in some cases might lead to weird-looking API, and have chosen to accept this compromise in order to get the safety checking offered to us by the compiler, and because of developers’ aversion to writing "@unchecked Sendable". We might not have needed to make this compromise if we had access to Swift 6 / iOS 18’s Mutex type, which allows for synchronous management of mutable state in a way that the compiler is happy with. But, none of the decisions here need to be final; we can see how we feel about the API as it evolves and as our knowledge of the language grows. [1] ably/specification#200 [2] ably/ably-cocoa#1962 [3] #33 (comment)
lawrence-forooghian
added a commit
that referenced
this issue
Aug 29, 2024
Part of #19. References to spec are based on [1] at commit aa7455d. I’ve decided to, for now, throw ably-cocoa’s ARTErrorInfo for consistency with JS; created #32 to revisit this later. We have decided (see [3]) that we’re going to try using actors as our mechanism for concurrency-safe management of mutable state. We accept that this will lead to more of the public API needing to be annotated as `async` (as has happened to Rooms.get here), which in some cases might lead to weird-looking API, and have chosen to accept this compromise in order to get the safety checking offered to us by the compiler, and because of developers’ aversion to writing "@unchecked Sendable". We might not have needed to make this compromise if we had access to Swift 6 / iOS 18’s Mutex type, which allows for synchronous management of mutable state in a way that the compiler is happy with. But, none of the decisions here need to be final; we can see how we feel about the API as it evolves and as our knowledge of the language grows. [1] ably/specification#200 [2] ably/ably-cocoa#1962 [3] #33 (comment)
lawrence-forooghian
added a commit
that referenced
this issue
Aug 29, 2024
Part of #19. References to spec are based on [1] at commit aa7455d. I’ve decided to, for now, throw ably-cocoa’s ARTErrorInfo for consistency with JS; created #32 to revisit this later. We have decided (see [2]) that we’re going to try using actors as our mechanism for concurrency-safe management of mutable state. We accept that this will lead to more of the public API needing to be annotated as `async` (as has happened to Rooms.get here), which in some cases might lead to weird-looking API, and have chosen to accept this compromise in order to get the safety checking offered to us by the compiler, and because of developers’ aversion to writing "@unchecked Sendable". We might not have needed to make this compromise if we had access to Swift 6 / iOS 18’s Mutex type, which allows for synchronous management of mutable state in a way that the compiler is happy with. But, none of the decisions here need to be final; we can see how we feel about the API as it evolves and as our knowledge of the language grows. [1] ably/specification#200 [2] #33 (comment)
lawrence-forooghian
added a commit
that referenced
this issue
Aug 29, 2024
Part of #19. References to spec are based on [1] at commit aa7455d. I’ve decided to, for now, throw ably-cocoa’s ARTErrorInfo for consistency with JS; created #32 to revisit this later. We have decided (see [2]) that we’re going to try using actors as our mechanism for concurrency-safe management of mutable state. We accept that this will lead to more of the public API needing to be annotated as `async` (as has happened to Rooms.get here), which in some cases might lead to weird-looking API, and have chosen to accept this compromise in order to get the safety checking offered to us by the compiler, and because of developers’ aversion to writing "@unchecked Sendable". We might not have needed to make this compromise if we had access to Swift 6 / iOS 18’s Mutex type, which allows for synchronous management of mutable state in a way that the compiler is happy with. But, none of the decisions here need to be final; we can see how we feel about the API as it evolves and as our knowledge of the language grows. [1] ably/specification#200 [2] #33 (comment)
Open
This was referenced Nov 21, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I’m currently just throwing ably-cocoa’s
ARTErrorInfotype, with custom error domain and new set of error codes. This is what the JS SDK does. The spec at time of writing also makes mention of errors with numeric codes. If we decide to stick with this approach, then we should expose some API in ably-cocoa to allow creating anARTErrorInfowith a customdomainandcause, to replace the copied-and-pasted code ininit(errorCode:).We also need to make sure that numeric error codes and status codes are consistent across platforms (the spec doesn't specify the error code or status code for all errors at time of writing).We might also decide that we wish to not use
ARTErrorInfoand instead create something more appropriate to Swift (i.e. that doesn't inherit fromNSError).Update: #45 has introduced other, non-
ARTErrorInfoerrors such asPaginatedResultErrorandMessagesError. Need to figure out what to do with those, too. It’s also throwing errors in the ably-cocoa error domain, which we need to revisit.┆Issue is synchronized with this Jira Story by Unito
The text was updated successfully, but these errors were encountered: