com.google.appengine.api.memcache

## Interface ErrorHandler

- All Known Subinterfaces:
    ConsistentErrorHandler
  All Known Implementing Classes:
    ConsistentLogAndContinueErrorHandler, LogAndContinueErrorHandler, StrictErrorHandler

      public interface ErrorHandler

  Handles errors raised by the `MemcacheService`, registered with `BaseMemcacheService.setErrorHandler(ErrorHandler)`.

  The default error handler is an instance of `LogAndContinueErrorHandler`. In most cases, this will log exceptions without throwing, which looks like a cache-miss behavior to the caller. A less permissive alternative is `StrictErrorHandler`, which will throw a `MemcacheServiceException` to surface errors to callers.

  To guarantee that all instances of `MemcacheServiceException` are directed to the error handler, use a `ConsistentErrorHandler` such as `ErrorHandlers.getConsistentLogAndContinue(Level)` or `ErrorHandlers.getStrict()`.

- - ### Method Summary

    All Methods Instance Methods Abstract Methods
    Modifier and Type | Method and Description
    --- | ---
    `void` | `handleDeserializationError(InvalidValueException ivx)` Handles deserialization errors.
    `void` | `handleServiceError(MemcacheServiceException ex)` Handles back-end service errors.

- - ### Method Detail

    - #### handleDeserializationError

          void handleDeserializationError(InvalidValueException ivx)

      Handles deserialization errors. This method is called from either of the `get` methods, if the retrieved value cannot be deserialized. This normally indicates an application upgrade since the cache entry was stored, and should thus be treated as a cache miss, which is the behavior of `LogAndContinueErrorHandler` (the default).

    - #### handleServiceError

          void handleServiceError(MemcacheServiceException ex)

      Handles back-end service errors. This method is called from most of the `MemcacheService` methods in the event of a service error. This is also called for `MemcacheService.put(Object, Object)` when the combined key and value size is too large.

      The handler may throw any `RuntimeException`, or it may simply return for "permissive" error handling, which will generally emulate behavior of a cache miss due to a discarded entry.

      Parameters:
        `ex` - the service error exception