mugle-dev team mailing list archive

[Matt Giuca <matt.giuca@xxxxxxxxx>]

> In that case the exceptions should be moved to the client API - the
> exceptions I created were as follows:
> AchievementNotExists - if the dev tries to look for or change the state of
> a user's achievement when an achievement with that name doesn't exist
> UserNotExists - if for some reason theres a user who doesn't exist playing
> the game (shouldnt happen)
> InvalidGameToken - the game token doesn't correspond to a game
> KeyValuePairNotExists - when checking the datastore for the existence of a
> key (so students can code for onFailure)
>

OK. I've just refactored all of that code and I consider the API
near-finalised. I didn't move those exceptions -- far too much code depends
upon them. I created new exceptions and internally caught the internal ones
and repackaged them in the API exceptions.

So this is a bit nuts internally and there's a bit of code / class
duplication, but that's OK because the API is very neat now, and we can
always refactor the implementation to use those API classes later.

What is with this "NotExists" name scheme?

AchievementNotExists: Wrapped as BadgeError.
UserNotExists: Now thrown silently as an error, without requiring the
developer to know about it (since it shouldn't happen).
InvalidGameToken: Wrapped as GameTokenError.
KeyValuePairNotExists: Currently caught and null is returned, since that was
the API I was coding to. We can discuss this at the meeting.

If you can, have a look over the new API before the meeting and see if
there's anything you think needs changing.