hey chuck,
my .02:
Charles Severance wrote:
Another thing that haunted me was the fact that a lot of portals will
just do stuff silently and not throw these exceptions - so when a
portlet comes to Sakai and sloppily lets a user try to set preferences
who does not have the right permissions and Sakai (totally compliantly)
throws the ReadOnly exception - it means their portlet breaks in Sakai
but not in more liberal containers. And if someone does not have source
to the war file - they can't even ad the catch block :(
Well, ReadOnlyException is a checked exception, so portlet authors must
have a catch block.
One is tempted to silently fail rather than throwing exceptions.
Either the author handles the exception in the catch, and
a) does the Right Thing (whatever that is in their context), or
b) the author swallows the exception and does nothing in the catch block
(a variant of c), or
c) does the Wrong Thing (bubble up a RuntimeException??).
If the author does:
a) no problem, right?
b) not good practice but you have your "silent failure" there
c) well, hey, what are ya gonna do?
Anyone with some comforting words about how "it is better to comply"
even if a few portlet writers get scorched :) ??
IMHO failing silently is not a good thing. Portlet authors have to
handle a ReadOnlyException so you have to count on the coder to handle
the exception gracefully.
Not sure if that helps or not!
Elliot
/Chuck
On Mar 5, 2007, at 12:15 PM, Stefan Hepper wrote:
Note that you normally should throw the read-only Exc when calling the
set methods and not and the end in the store in order to be compliant
with the JSR 168 spec. It is in the spirit of the spec that you can
get this exc if the current user does not have sufficient rights to do
this (i.e. that the preference is read-only for this request).
Stefan
