Change request for: /docs/api/rest-sdk/types

[DancecardJK]

Page name: Types
URL: /docs/api/rest-sdk/types
Language: JavaScript

Requested change or enhancement:

1. https://ably.com/docs/api/rest-sdk/types#error-info
   The ErrorInfo object's "cause" property says it has a default type of "ErrorInfo" (in the Swift SDK, this is implemented as an "ARTErrorInfo?" type (optional)). Is it intended that ErrorInfo objects should be able to nest recursively? If so, would it be possible to put a bit of explanatory text in there as to how that's meant to work and be used on the client end?

2. When trying to deliberately evoke an error with ARTRealtime with MAP_CREATE, I found that this subdomain worked without complaint, when maybe it shouldn't?

let path = "https://dangerismymiddlename.realtime.ably.net/channels/\(channelName)/objects"

3. When trying to deliberately evoke an error with ARTRealtime, the ARTErrorInfo object always seems to return nil, so it seems superfluous for at least the ARTRealtime client (this is harmless, and I understand this might just be a temporary thing while you guys are working on it, so it's no big deal). (BUT on the other hand, the ARTHTTPPaginatedResult does contain a meaningful errorCode and errorMessage, which is great. :) )

4. https://ably.com/docs/api/realtime-sdk/types?lang=swift#paginated-result-example
   In this Swift example there is some unsafe code (basically anywhere there's an exclamation mark). Rather than:

   let paginatedResult = paginatedResult! // <--- If paginatedResult (which is optional) is ever nil, this will crash out 😵

Instead you could write this as:

`guard let paginatedResult`  // <-- This will safely unpack the optional, and exit the function gracefully if it's nil
`else { print("No results"); return }`

Thanks! :)

[paddybyers]

1. The ErrorInfo object's "cause" property says it has a default type of "ErrorInfo" (in the Swift SDK, this is implemented as an "ARTErrorInfo?" type (optional)). Is it intended that ErrorInfo objects should be able to nest recursively? If so, would it be possible to put a bit of explanatory text in there as to how that's meant to work and be used on the client end?

Yes, this is the principle, but in practice there are very few places where this happens. But the idea is that an error can be returned, and its code tells you something about why the attempted operation failed, and the cause can provide more information on any underlying reason.

One example is if invocation of an authURL or authCallback fails when attempting to renew an auth token. The ErrorInfo will have the specific code 80019, which tells you that it was unable to renew the token because of a failure in the renewal prcoess, but a nested ErrorInfo in the cause will contain the error response from the authURL if any (see https://faqs.ably.com/error-code-80019).

I found that this subdomain worked without complaint, when maybe it shouldn't?
let path = "https://dangerismymiddlename.realtime.ably.net/channels/\(channelName)/objects"

When you say it worked, what specifically did you try that worked? The name doesn't resolve, so it's possible that the client was happy for you to specify that endpoint and perform some local operations, but it would not have been able to connect.

In this Swift example there is some unsafe code
...

Thanks, we'll update.