Dear Marc,
You are totally right about the good practices for java exceptions, and I
can only agree with you.
However, these interfaces are only a temporary facade wrapping the oldcore
module. These are useful to avoid dependency on oldcore for modules that
use IoC and require some access to data. These have been require to support
our progressive refactoring of the oldcore into independent modules, simply
to avoid circular dependencies.
Since our oldcore throws com.xpn.xwiki.XWikiException, you already knows
what those exceptions are hiding, and being explicit would have simply
defeated the initial purpose, since XWikiException is define in the oldcore
module.
Until we have extracted the model and storage access out of the oldcore,
these interface will have to stay. Of course, we have plans for new model
and storage, but nothing is in our short term roadmap. You may read more
about XWiki improvement proposals on
design.xwiki.org (ie: search for model
or storage), and our current roadmap at
http://www.xwiki.org/xwiki/bin/view/Roadmaps/
You are free to help us progress toward these goals ;)
Regards,
On Tue, May 5, 2015 at 3:45 PM, Marc Sladek <marc.sladek(a)synventis.com>
wrote:
Dear XWiki devs
I recently wanted to refactor the usage of XWikiContext and XWikiDocument
in my code with DocumentAccessBridge and DocumentModelBridge.
I however was suprised that many methods in DocumentAccessBridge throw
java.lang.Exception. This is generally considered bad practice since it
forces all clients to catch java.lang.Exception and therefore also
unchecked Exceptions - from which the client potentially can't or shouldn't
recover.
For in depth arguments see e.g. Joshua Bloch's "Effective Java" where he
states to "use checked exceptions for recoverable conditions and runtime
exceptions for programming errors", "throw exceptions appropriate to the
abstraction" and "always declare checked exceptions individually".
Can somebody explain to me the reasoning behind throwing
java.lang.Exception in this interface? Are there any plans to deprecate and
replace it by an interface without this caveat?
Thanks
Marc
synventis GmbH
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO