@awoods can you rebase this PR against fcrepo4/master?

@acoburn, rebased.

Travis appears to have failed. Also, are we confident that all places that Jena might throw a RuntimeIOException are places from which we want to map as done here?

Alternatives to mapping the Jena RuntimeIOException are to:

• inspect the cause of the RuntimeIOException looking for JsonParseException, or
• specifically wrap this statement: https://github.com/fcrepo4/fcrepo4/blob/master/fcrepo-http-api/src/main/java/org/fcrepo/http/api/ContentExposingResource.java#L581

However, the Jena exception seems likely to be the result of a BAD_REQUEST scenario.
Regarding Travis, the branch builds locally. Probably a sporadic test error.

I'd rather take wrap the statement and check for the cause. RuntimeIOException is really generic. We could easily catch it and throw something more meaningful.

Sure. The downside, of course, is that there may be other places in the code that would benefit from a Jena RuntimeIOExceptionMapper.

Can we be sure what to produce (HTTP) for the generic case?

Can you clarify that question?

It's the same question with which I started. If you only have a RuntimeIOException and nothing else, can you be sure you know (in a mapper) what HTTP response to produce?

I would answer that question with, "yes", since this particular scenario is the first time the RuntimeIOException has surfaced.

However, if you would feel more comfortable with:

• wrapping the specific location in ContentExposingResource, followed by
• inspecting the RuntimeIOException cause, followed by
• throwing a Fedora-specific exception (MalformedRdfException ??) that is caught by its own exception-mapper, I would be happy to add a new commit.

I honestly would. The semantics of RuntimeIOException are just what you'd think (just an unchecked IOException). I think rethrowing something (sure, MalformedRdfException, when that's appropriate) inside our code is cleaner. Especially if it turns out that there are several ways for the problem to happen (besides a purely empty body) and we want to distinguish them.

New commit responds to comments.
@ajs6f, let me know if this looks good to you. If so, I will squash the two commits.

Yeah, I like that much better. Thanks!