mugle-dev team mailing list archive

[Matt Giuca <matt.giuca@xxxxxxxxx>]

I am making extensive changes to the API now.

One thing that I've noticed has changed since I took a copy of the API is
that the API now declares a lot of exceptions from mugle.shared.platform to
be thrown. I assume this is because the possibility of those exceptions came
up in the implementation. We can talk about it today, but however we resolve
it, it is not acceptable for the API to depend on any classes in
mugle.shared.platform.

The client side of the API (mugle.client.api and mugle.shared.api) must be
independent, since we will give just those classes to the developers.
Therefore I am removing these exception declarations.

We need to separate the extensions into two varieties:

   - Those which might legitimately be thrown as a result of the developer
   doing something wrong or a legitimate state the database may be in which
   doesn't support that operation right now.
   - Those which cannot be thrown except if something has gone wrong in the
   back-end.

Note that Java offers two base classes for these two conditions: The former
should extend java.lang.Exception and the latter should extend
java.lang.Error. The latter does not require a throws declaration.

I see there is now a mugle.shared.platform.exceptions.InvalidGameToken error
-- that's fine for our internal use, but for the developer-facing API I will
change it to throw a mugle.shared.api.GameTokenError. Did we agree that
KeyValueService would throw an error if it couldn't find the key? I also
have a badge error -- note that I have extensively changed the Badge API.
For the remaining exceptions I think they are better classified as Errors --
these may be sent up to the developer and they can still catch them and
print their error messages, but they do not need to be explicitly mentioned
in the throws declaration.