* Exception handling: we have the notion of retryable versus non-retryable operations. These are encapsulated by `BaseServiceException`. Retryable error codes should be listed in the service's subclass of `BaseServiceException`. An operation should be considered retryable if it makes sense to retry (e.g. if there was a transient service error, not a fundamentally invalid request) and if the operation that triggered the exception is idempotent. Exceptions also contain information regarding whether the service rejected the request, meaning the operation was not applied. The `BaseServiceException` subclass should also provide methods to translate the exceptions given by the underlying autogeneraged client library. The [`ExceptionHandler`](https://github.com/GoogleCloudPlatform/google-cloud-java/blob/master/google-cloud-core/src/main/java/com/google/cloud/ExceptionHandler.java) class intercepts and retries RPC calls when retryable exceptions are encountered. Note that some exceptions are masked in the SPI layer. For example, `get` and `delete` operations often return "404 Not Found" if the resource doesn't exist. Instead of throwing an exception in these cases, we often return `null` for `get` and `false` for `delete`.

Notes/reminders:

* API layer classes should be located in the package `com.google.cloud.servicename`, where "servicename" corresponds to the name of the Google Cloud service.

API-level functionality should be well-covered by unit tests. Coders and reviewers should examine test coverage to ensure that important code paths are not being left untested. As of now, `google-cloud` relies on integration tests to test the SPI layer. Unit tests for the API layer should be located in the package `com.google.cloud.servicename`. Integration tests should be placed in a separate package, `com.google.cloud.servicename.it`, which enables us to catch method access bugs. Unit tests for the test helper should be placed in the package `com.google.cloud.servicename.testing`. All unit tests run for pull requests, but integration tests are only run upon merging the pull request. We only run integration tests upon merging pull requests to avoid decrypting and exposing credentials to anybody who can create a pull request from a fork. Prefix integration test file names with "IT" (e.g. `ITDnsTest`) to separate them from regular unit tests.