Skip to content

Error handling refactor #354

Description

@hiranya911

We are in the process of implementing a large-scale refactor of our exception types. This is largely a breaking change, and therefore will be released in the next major version (no concrete timeline yet). The benefits of this refactor include:

  1. Clearly defined top-level error codes for all exceptions, where error codes follow the specification in https://cloud.google.com/apis/design/errors.
  2. Ability to provide both a top-level and service-specific error codes for some exceptions.
  3. Ability to access HTTP response (including content and headers) via exceptions.
  4. Clear separation between developer errors, and backend errors.

The overall API changes planned as part of this refactor are outlined below (taking FCM as an example):

class OutgoingHttpRequest {
  String getMethod()
  String getUrl()
  HttpContent getContent()
  Map<String, Object> getHeaders()
}

class IncomingHttpResponse {
  int getStatusCode()
  String getContent()
  Map<String, Object> getHeaders()
  OutgoingHttpRequest getRequest()
}

enum ErrorCode {
  INVALID_ARGUMENT,
  INTERNAL,
  UNAVAILABLE,
  // ... other top-level error codes
}

class FirebaseException extends Exception {
  ErrorCode getErrorCode();
  String getMessage();
  Throwable getCause();
  IncomingHttpResponse getHttpResponse()
}

enum MessagingErrorCode {
  UNREGISTERED,
  SENDER_ID_MISMATCH,
  // ... other FCM error codes
}

class FirebaseMessagingException extends FirebaseException {
  MessagingErrorCode getMessagingErrorCode();
}

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions