4xx call throws DioError which exposes implementation details

[JulianBissekkou]

The lib uses dio internally which forces consumers to catch the error if an unsuccessful call throws a DioError.
We currently use this helper method to map unsuccessful calls to own exception/other exception types.

// Some calls fail because Dio is used internally and this will throw instead
  // of returning a 4xx response.
  Future<R> _catchApiErrors<R>(FutureOr<R> Function() call) async {
    try {
      return await call();
    } on DioError catch (error) {
      if (error.response.statusCode == 401) {
        throw ApiException.unauthorized(); // own exception type

      }
      rethrow;
    }
  }

I just want to point out that this is not an issue atm, but it might be a nice thing to improve.
Feel free to close this issue 👍

[eldadfux]

@lohanidamodar let me know if you see any reason why not to add an "Appwrite" Exception to the Flutter SDK. Personally I don't see any, but I guess it would be nice to add this feature to all supported SDKs

[JulianBissekkou]

why not to add an "Appwrite" Exception to the Flutter SDK

Can you maybe explain what this exactly means? 🤔

[eldadfux]

@JulianBissekkou I was thinking we can detect the Appwrite-related DIO error at the Appwrite SDK itself and then throw an instance of an Appwrite custom exception for easier detection of the different exception. Did I miss something?

[lohanidamodar]

@eldadfux Yes I believe it's best to introduce Appwrite exception to all our SDKs including Flutter.

[JulianBissekkou]

Appwrite-related DIO error at the Appwrite SDK itself and then throw an instance of an Appwrite custom exception for easier detection of the different exception. Did I miss something?

Perfect!

@lohanidamodar
Sounds good.

Maybe it makes sense to introduce different exceptions extending the appwrite exception. For example rate limits can throw a specific exception. 🤔

[lohanidamodar]

@JulianBissekkou yes love the idea, it should definitely be multiple exceptions based on a base exception.

[JulianBissekkou]

Great!
Side question: Why did you choose dio for network calls? I see many flutter devs that use dio for really basic http stuff and I always think that the default http client can do all of that as well 🤔

What feature were you missing?

[eldadfux]

@JulianBissekkou The first versions of the SDK were contributed by a few of the community members. I don't remember exactly what was missing at the time. If native HTTP client can do multipart/form request and handle cookies we might be able to drop it and reduce the dependency tree.

[JulianBissekkou]

Multipart will work, cookies probably not. But dio is fine, I was just curious ☺️

[lohanidamodar]

@JulianBissekkou We really appreciate your feedback. And here we have been working with throwing custom exceptions from our SDKs and Have a RFC and started working.

• RFC
• Work on Flutter SDK
  Please provide us with your valuable comments, feedback on whether or not it meets your expectation

For Flutter SDK, the SDK will throw an instance of AppwriteException which will have following information

• message: Actual error message from server response, if server response is null, the error message will mostly be Dio error message
• response: actual response data from the server
• code: the error code received from the server, mostly will be Http status code

[JulianBissekkou]

I quickly checked out the flutter SDK branch and dropped a few comments. 👍

What about specific error codes? For example, I want to display a message if the account is blocked.
The AppWrite server will provide a 401 or 403 (not sure) but the information that the account is blocked is not included.

An additional code would be helpful in this case.
I am not sure if this is already implemented, but I couldn't find it in the "Create Account Session" Docs.

[eldadfux]

The extra info would be provided as part of the exception message.

[eldadfux]

A new Appwrite exception has been added to v0.4.0 which is now out of dev channel