The method getContentStream is specified to return CmisConstraintException when there is no content stream or rendition stream, and it's this case that we would turn into null. The other exceptions would be let through. Only for the case where the repository returns a non-specified CmisConstraintException would we have an ambiguity, but I don't think it would be problematic as the end-result would still be the same: no content stream available.
In general I don't think the high-level APIs should be made inconvenient to cover edge cases that do not matter in real life. The application programmer still has the option of getting down to the bindings level if he wants that fine a control... Florent On Wed, Sep 15, 2010 at 2:04 PM, Florian Müller <[email protected]> wrote: > Hi Florent, > > I can see that it is more convenient if the getContentStream() would return > null in this case. > > On the hand, the exception could carry important information such as what > caused the error: the objectId or the streamId. This information would be > lost. > > > - Florian > > > > On 14/09/2010 17:20, Florent Guillaume wrote: >> >> Hi, >> >> The domain model says that getContentStream should throw a constraint >> exception when there is no content stream. >> >> For the bindings this should mean CmisConstraintException, although >> the AtomPub bindings currently return a CmisNotSupportedException due >> to the missing link. >> >> For the session I thing doc.getContentStream() should return null in >> that case instead of throwing, what do you think? >> >> Florent >> > > -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
