• Views
  • Iteration Report
  • My Iteration Report
  •  
OMERO.server
  • Login
  • Help/Guide
  • About Trac
  • Preferences
  • Wiki
  • Timeline
  • Roadmap
  • Browse Source
  • View Tickets
  • Search

Context Navigation

  • Start Page
  • Index
  • History
  • Last Change

Exception Handling

Interceptor

Table of Contents

  1. Interceptor
  2. Hierarchy
  3. Discussion
  4. Questions

Exception handling in the OMERO is centralized in an OmeroAop? interceptor (source code). All exceptions thrown by code are caught in a try {} catch (Throwable t) {} block. Exceptions which don't subclass ome.conditions.RootException are wrapped in an ome.conditions.InternalException.

The only exceptions to this are any interceptors which may be run before the exception handler is run. The order of interceptors is defined in services.xml.

Hierarchy

The current exception hierarchy (package ome.conditions) used is as follows:

  • RootException
    • InternalException : shouldn't reach the client; Bug! Contact administrator. E.g. NullPointerException, assertion failed, etc.
    • ResourceError : fatal error in server. E.g. OutOfMemory, disk space full, DB is in illegal state, etc.
    • DataAccessException
      • SecurityViolation : don't do that! E.g. edit locked project, create new user.
      • OptimisticLockException : re-load and compare. E.g. "someone else has already updated this project"
      • ApiUsageException : something wrong with how you did things. E.g. IllegalStateException, object uninitialized, etc.
      • ValidationException : something wrong with what you sent; sends list of fields, etc.; edit and retry. E.g. no "?" in image names.

where the colors indicate:

Abstract
FixAndRetryConditions
RetryConditions
NoRecourseConditions

Any other exception which reaches the client should be considered an OutOfServiceException, meaning that something is (hopefully only) temporarily wrong with the server. E.g. No connection, server down, server restarting. But since this can't be caught since the server can't be reached, there is no way to guarantee that a real OutOfServiceException is thrown.

Discussion

FixAndRetryConditions need to have information about what should be fixed, like a Validation object which lists fields with error messages. A RetryCondition could have a backoff value to prevent too frequent retries.

Questions

* What data should be available in the exceptions? * What other logic do we want on our exceptions, keeping in mind they will have to be re-implemented in all target languages?

Download in other formats:

  • Plain Text

Trac Powered

Powered by Trac 0.11
By Edgewall Software.

Visit the Trac open source project at
http://trac.edgewall.org/