Maybe it's worth it here but I'm always wary of applying semantics to a library exception class that aren't part of its original meaning.  What if someone has the following slightly-but-not-really-that lazy code somewhere:
```python
try:
   domain = Domain.get_by_name(some_name)
except ResourceNotFound:
   raise ApplicationError("Couldn't find that domain")

and then extends it in a not unimaginable way:
```
```python
try:
   domain = Domain.get_by_name(some_name)
   form = Form.get_form(some_id)
   # do something with form and domain
except ResourceNotFound:
   raise ApplicationError("Couldn't find that domain")
```

Boom,  buggy code.

Or what if someone is just reading xform_display and gets the mistaken impression that Form.get_form has an underlying call to SomeDocument.get(id) rather than SomeView.view(...) because they know that ResourceNotFound is only thrown by couchdbkit in one place in its entire codebase, in Document.get(), and then does something based on that mistaken understanding?

Is this way really better than either creating a new FormNotFound exception class or the like, or just calling .one()['value'] like it was originally and in xform_display() catching the NoResultFound exception that's already thrown by couchdbkit when you call one() and there aren't any results? (An example of pretty useful abstraction provided by ViewResults, it would seem.)