[jira] [Commented] (JENA-2192) JENA's Model#read should throw checked exception(s) instead of RuntimeException(s)

["Andy Seaborne (Jira)" <ji...@apache.org>]

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

Andy Seaborne commented on JENA-2192:
-------------------------------------

The NPE is most likely a separate issue. NPEs should not happen. Please show the input and stacktrace.

{quote}
try/catch RuntimeException
{quote}

Presumably, it is the catching of a general RuntimeException that causes the SONAR complaints. If you catch something more specific - JenaException or RiotException then these should go away (otherwise SONAR is saying never use runtime exceptions!).

All parse errors should become a RiotException unless you have configured a different error handler.

You've recognized the main issue of changing the API and forcing (there is not progressive way of introducing checked exceptions that I can see) users to change their code.

Parsing normally happens in only a few places in an application. If you want, you can put all your use of parsing in a library and have checked exceptions. So you can already do it if you want.

Checked exceptions don't make code less cumbersome. Either they force adding try-catch which often will be ignored or many methods up the call stack will add "throws JenaException" which hasn't really changed the situation in any useful way. IOException - and because it is about external resources, the case of forcing error handling is reasonable - suffers from this where it is used on anything that isn't a primitive like "read", "write". try-with-resources works satisfactorily and Jena has moved for the large part to either managing I/O streams internally or accepting app-managed I/O streams.

But also - checked exceptions don't have as much applicability as they used to. 

Checked exceptions do not interact well with lambda expressions or Java streams. Jena could need to provide versions of Consumer, Supplier and the rest which handled exceptions and likely they would be a bland "throws Exception" and the situation has not changed.

c.f. Kotlin and Scala
They don't have checked exceptions.

> JENA's Model#read should throw checked exception(s) instead of RuntimeException(s)
> ----------------------------------------------------------------------------------
>
>                 Key: JENA-2192
>                 URL: https://issues.apache.org/jira/browse/JENA-2192
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Jena
>    Affects Versions: Jena 4.2.0
>            Reporter: Henry Kuijpers
>            Priority: Major
>
> We have noticed that, when parsing a document using JENA's Model#read, a) there are no checked exceptions specified and b) when parsing fails, runtime exceptions are thrown.
> This makes it a bit cumbersome to catch cases where parsing goes wrong. One option is to wrap the statement in try/catch RuntimeException, however, this doesn't seem to be a good practice (and Sonar complains to us about it).
> We've seen some cases:
> * Malformed XML (normal XML parsers would fail also)
> * NPEs (in case the RDF standard is not properly followed and/or elements are pointing to unexisting items)
> I realize that adding a throws-declaration in the parse-method would be an API change, but as long as that is put in the release notes and done with a major version increase, I think that should be fine.
> WDYT?



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