Revisit the errors thrown by library #32

lawrence-forooghian · 2024-08-29T10:27:26Z

I’m currently just throwing ably-cocoa’s ARTErrorInfo type, 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 an ARTErrorInfo with a custom domain and cause, to replace the copied-and-pasted code in init(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 ARTErrorInfo and instead create something more appropriate to Swift (i.e. that doesn't inherit from NSError).

Update: #45 has introduced other, non-ARTErrorInfo errors such as PaginatedResultError and MessagesError. 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 Task by Unito

The text was updated successfully, but these errors were encountered:

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

@unchecked

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)

@unchecked

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)

@unchecked

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)

@unchecked

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)

@unchecked

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 the enhancement New feature or improved functionality. label Aug 29, 2024

lawrence-forooghian mentioned this issue Aug 29, 2024

[ECO-4936] Implement the ability to fetch a room #33

Merged

coderabbitai bot mentioned this issue Sep 23, 2024

[ECO-4952] Start implementing room lifecycle spec #54

Merged

lawrence-forooghian mentioned this issue Sep 23, 2024

[ECO-4942] Send/Receive Messages Spec Complete #45

Merged

coderabbitai bot mentioned this issue Nov 12, 2024

UTS chat adapter #90

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Revisit the errors thrown by library #32

Revisit the errors thrown by library #32

lawrence-forooghian commented Aug 29, 2024 •

edited

Loading

Revisit the errors thrown by library #32

Revisit the errors thrown by library #32

Comments

lawrence-forooghian commented Aug 29, 2024 • edited Loading

lawrence-forooghian commented Aug 29, 2024 •

edited

Loading