[
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)
