Yup, it definitely was a pain ;-). But I found *so* many potential
NPE situations while doing it it was embarrassing.
However, what I didn't do was to review the rest of the WikiEngine API
to see if the methods throw the proper exceptions. Some of them might
be throwing ProviderExceptions, and since PageNotFoundException is a
PE, we might want to put it separately in the signature so that it can
be properly documented.
(Switched to dev-list).
/Janne
On 16 Mar 2009, at 02:20, Andrew Jaquith wrote:
Any objection to me changing the various WikiEngine.getPage() methods
so that they throw a PageNotFoundException instead of returning null?
Yeah, it's sort of a pain to do in the short term, but NOT doing it is
proving problematic in the 3.0 codebase.
On Thu, Mar 12, 2009 at 2:28 PM, Janne Jalkanen
<[email protected]> wrote:
Except that in this case, our API has defined that getPage()
returns null if
the page is not found. In JCR, however, not finding an item is
considered
to be an exception, so unless we change the way we work, it is
mandatory.
For all other exceptions, we catch and propagate them upwards
properly.
/Janne
On Mar 12, 2009, at 20:24 , Foster Schucker wrote:
+1 providing something catches the exception and DOES something
with it.
Just catching and returning null is worse.
Harry Metske wrote:
+1
2009/3/12 Janne Jalkanen <[email protected]>
Simple enough reason: getPage(WikiName,int) is not catching the
PathNotFoundException - look at the catch clause in
getPage(WikiName)
;-).
It should do that and return null.
My bad, sorry!
(A general question, should we start throwing something like
PageNotFoundExceptions as opposed to returning nulls? That would
encourage a
bit safer coding and would eliminate a number of if(getPage() ==
null)
tests
across the codebase.)
/Janne
