[documentation] document possible exceptions.

[GregorySech]

It would be nice to have a list of known exceptions (or even better an exception/error hierarchy) that can be thrown by the various Flutterfire packages and their APIs.

As those exceptions are not documented error handling is, at best, a shot in the dark.
At worse gets people to publish apps that will not gracefully fail.

For example giving feedback to the user when retrieving data from Firestore or RTDB goes wrong is particularly gnarly.
Right now those packages users are thorn between printing out the exception or giving way too generic errors to theirs users.

[panthe]

I think that the description of errors are a feature very important. In this moment in Flutterfire they are imbarazzing. Please improve it...

[collinjackson]

I agree that it would be better to provide dedicated exception classes for all the errors that we're expecting the developer to handle, and fall back to PlatformException for anything that Flutterfire doesn't explicitly handle. If anyone would like to take a crack at writing a PR for one plugin I'd be happy to review the approach and then we can extend it to the other plugins.

[GregorySech]

After looking at the Android reference for most packages it seems that using a hierarchy needs some planning as almost no official SDK uses them between the various platforms. I'm not sure if using it here is a good idea, maybe I'd keep the already used pattern of PackageException + code. It has already been adopted in a few packages including Auth with flutter/plugins#775.

I think this is pretty much the best possible way to handle exceptions in the other plugins.

Some seem to already use a similar approach i.e. Storage.

If I'm free in the weekend I'll try to take one of the APIs with gRPC based errors like firestore.

[yamauchieduardo]

Also clarification about exceptions and errors related in #1320