DOH! I didn't follow the chain far enough up the list. I see now that JenaException extends RuntimeException..... problem solved.
On Mon, Jul 13, 2015 at 10:45 PM, Andy Seaborne <[email protected]> wrote: > On 13/07/15 21:52, Claude Warren wrote: > >> After reviewing the Permissions code I find an issue that I am not sure >> how >> to resolve. >> >> There are a number of methods in SecuredGraph that can throw the current >> AccessDeniedExceptionwhich extends RuntimeException. >> > > Why not extend JenaException? Or OperationDeniedException? > > I suppose I can create an AccessDeniedRuntime exception so that I can >> throw >> it from methods like Graph.find() where a ReadDeniedException would be >> appropriate. >> > > Yes. > > I think the choice of exceptions names/types will be down to the > permissions code which is, architecturally, another graph implementation. > An implementation can introduce it's own exceptions to reflect it's own > facilities. It isn't going to be documented in the Graph interface when > there are SecuredGraph specifics involved. > > As now any operation in Graph can potentially throw a runtime exception, > logically add/delete could have their "throws" removed. They are an > artifact of one point-of-view really. > > I don't want to force massive exception processing changes on the rest of >> the code. >> If anyone has a suggestion I would like to hear it. >> >> Claude >> >> >> AccessDeniedException >> >> On Mon, Jul 13, 2015 at 1:00 PM, Claude Warren <[email protected]> wrote: >> >> That sounds reasonable. >>> >>> So what we would have is >>> {noformat} >>> OperationDeniedException >>> | >>> AccessDeniedException >>> | >>> >>> >>> +----------------------------+------------------------+--------------------------+ >>> | | | >>> | >>> AddDeniedException DeleteDeniedException >>> UpdatedeniedException ReadDeniedException >>> >>> {noformat} >>> >>> Claude >>> >>> On Mon, Jul 13, 2015 at 12:26 PM, Andy Seaborne <[email protected]> wrote: >>> >>> On 13/07/15 12:03, Claude Warren wrote: >>>> >>>> I would like to rename the UpdateDeniedException to >>>>> AccessDeniedException. >>>>> AddDeniedException, DeleteDeniedException currently extend it. >>>>> >>>>> jena-permissions will then extend that to create: >>>>> ReadDeniedException -- for read restrictions >>>>> UpdateDeniedException -- for update restrictions (modifying triples >>>>> that >>>>> already exists as opposed to adding new triples) >>>>> >>>>> I think that this will allow Fuskei to properly respond to the case >>>>> where >>>>> jena-permissions is in place and there are update restrictions in >>>>> place. >>>>> Currently Fuseki returns this as a 500 error. Once we have a common >>>>> permission denied exception we can return either authentication >>>>> required >>>>> or >>>>> access denied as appropriate. >>>>> >>>>> Thoughts? >>>>> Claude >>>>> >>>>> >>>>> I agree that the existing name isn't so good nowadays. >>>> >>>> I wonder if "access" is best reserved for permissions exceptions and >>>> have >>>> a bland "can't do that" to cover both access denied situations and >>>> operartion not appropriate (delete from a append-only or read-only >>>> graph). >>>> >>>> How about "OperationDeniedException" as the root of all refusals, then >>>> AccessDeniedException used as the root of all permissions exceptions >>>> (whether defined in jena-permission or just this top level one in >>>> jena-core >>>> and all subclasses with meaning in jena-permission). >>>> >>>> Then Fuseki can catch AccessDeniedException and respond with 401,403 and >>>> still have different handling for non-permissions related exceptions >>>> (e.g. >>>> 400 Bad Request for update a read-only graph where other parts of a >>>> datasets are mutable). >>>> >>>> Andy >>>> >>>> >>>> >>> >>> -- >>> I like: Like Like - The likeliest place on the web >>> <http://like-like.xenei.com> >>> LinkedIn: http://www.linkedin.com/in/claudewarren >>> >>> >> >> >> > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
