Infrastructure

There are three main options for how to do this:
1. use SerializationException
2. use javax.xml.bind.JAXBException and subclasses (MarshalException / ValidationException / UnmarshalException / PropertyException)
3. define our own exception

1. SerializationException is a RuntimeException, so changing to it would be change in behavior as well as name - throwing an unlikely - handled runtime exception.

2. JAXB (and along with it, JAXBException) is Java standard so users would get the benefit of subclasses if libraries decide to throw them. JAXB also un/marshals JSON, so it's placement inside an "xml" package is somewhat misplaced, but likely to be durable. DataONE could use the general JAXBException or its subclasses. "JAXBException" is not very transparent, but using the more transparent MarshalException / UnmarshalException doesn't handle all exceptions thrown by JAXB = marshal methods throw MarshalException as well as JAXBException. It is difficult to imagine differential actions taken by users, which argues against taking advantage of the subclasses.

3. Defining our own exception(s) is probably the most durable and least confusing for DataONE users, and would keep the method signatures simple. Implementation-specific detail would be accessible (although not easily actionable by setting the cause when thrown (for example: throw new MarshallingException("oops",theJAXBException).

All things considered, and after discussion, option 3 is chosen.