Skip to content

A few API doc updates #340

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Sep 10, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions firebase_admin/exceptions.py
Original file line number Diff line number Diff line change
Expand Up @@ -15,16 +15,16 @@
"""Firebase Exceptions module.

This module defines the base types for exceptions and the platform-wide error codes as outlined in
https://cloud.google.com/apis/deesign/errors.
https://cloud.google.com/apis/design/errors.

:class:`FirebaseError` is the parent class of all exceptions raised by the Admin SDK. It contains
the ``code``, ``http_response`` and ``cause`` properties common to all Firebase exception types.
Each exception also carries a message that outlines what went wrong. This can be logged for
audit or debugging purposes.

When calling an Admin SDK API, developers may catch the parent ``FirebaseError`` and
inspect its ``code`` to implement fine-grained error handling. Alternatively, developers may
catch one or more subtypes of ``FirebaseError``. Under normal conditions, any given API may raise
When calling an Admin SDK API, developers can catch the parent ``FirebaseError`` and
inspect its ``code`` to implement fine-grained error handling. Alternatively, developers can
catch one or more subtypes of ``FirebaseError``. Under normal conditions, any given API can raise
only a small subset of the available exception subtypes. However, the SDK also exposes rare error
conditions like connection timeouts and other I/O errors as instances of ``FirebaseError``.
Therefore it is always a good idea to have a handler specified for ``FirebaseError``, after all the
Expand Down
2 changes: 1 addition & 1 deletion firebase_admin/messaging.py
Original file line number Diff line number Diff line change
Expand Up @@ -295,7 +295,7 @@ def success(self):

@property
def exception(self):
"""A FirebaseError if an error occurs while sending the message to the FCM service."""
"""A ``FirebaseError`` if an error occurs while sending the message to the FCM service."""
return self._exception


Expand Down