You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Angela Schreiber (Jira)" <ji...@apache.org> on 2021/08/11 09:23:00 UTC

[jira] [Commented] (SLING-10705) Improve exception handling and error reporting

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

Angela Schreiber commented on SLING-10705:
------------------------------------------

[~cziegeler], sounds good to me..... i don't know why the original authors decided to throw generic RuntimeException/IllegalStateException but being more specific and properly distinguishing between input-errors and tool-internal-errors sounds good. i noticed it before but since there is a similar pattern used in repo-init, i somehow assumed that this was on purpose.

> Improve exception handling and error reporting
> ----------------------------------------------
>
>                 Key: SLING-10705
>                 URL: https://issues.apache.org/jira/browse/SLING-10705
>             Project: Sling
>          Issue Type: Improvement
>          Components: Content-Package to Feature Model Converter
>            Reporter: Carsten Ziegeler
>            Assignee: Carsten Ziegeler
>            Priority: Major
>             Fix For: Content-Package to Feature Model Converter 1.1.8
>
>
> The code is currently not distinguishing between user errors and tooling errors. For example an IllegalStateException might be thrown if an OSGi configuration is in the wrong place inside the content package as well as if there is an internal error inside the tool.
> While the first category of errors can be fixed by users fixing/adjusting their code/content packlages - the second category hints at bugs in the code.
> However both are reported exactly the same way.
> I suggest we report the first one as errors via logging while the second one throws an exception to the "outside".
> We can probably achieve this without much effort by using a special exception type for the first category.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)