[jira] [Commented] (SLING-11067) Extend URIProvider to not rely on exceptions if URIs can not be provided for a resource

["Carsten Ziegeler (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-11067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711678#comment-17711678 ] 

Carsten Ziegeler commented on SLING-11067:
------------------------------------------

I think we should resolve this issue one way or the other. As discussed in the PR, I don't think it is worth breaking implementations for this change. This is not a mainstream interface and dealing with the exception is imho acceptable.

> Extend URIProvider to not rely on exceptions if URIs can not be provided for a resource
> ---------------------------------------------------------------------------------------
>
>                 Key: SLING-11067
>                 URL: https://issues.apache.org/jira/browse/SLING-11067
>             Project: Sling
>          Issue Type: Improvement
>          Components: API
>            Reporter: Konrad Windszus
>            Assignee: Konrad Windszus
>            Priority: Major
>          Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> Currently URIProvider is not allowed to return null according to https://github.com/apache/sling-org-apache-sling-api/blob/333fa20f07a1d42897c9e0b6253bec5dcedb3e0b/src/main/java/org/apache/sling/api/resource/external/URIProvider.java#L48.
> This forces every URIProvider to throw an exception for the (pretty common) case it cannot provide a URI for a resource.
> As creating exceptions comes with quite some overhead, I would propose to enhance that interface.
> As just allowing null return values would be backwards-incompatible I would propose to instead add a second method called {{Optional<URI> getOptionalUriForResource(Resource, Scope, Operation)}} with a default implementation which calls {{toUri(...)}} and properly catches and logs IllegalArgumentExceptions. At the same time I would deprecate the existing method {{toURI(...)}}.
> Compare with the discussion at https://lists.apache.org/thread/xfgmrxbv6n1k5y57v6kq9pxnkyr6hcyb



--
This message was sent by Atlassian Jira
(v8.20.10#820010)