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.
-- Mailing list: https://launchpad.net/~mugle-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~mugle-dev More help : https://help.launchpad.net/ListHelp
