[
https://issues.apache.org/jira/browse/SOLR-8260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15009440#comment-15009440
]
David Smiley commented on SOLR-8260:
------------------------------------
I just reviewed this patch. One thing I'm seeing here that I _usually_
consider to be a (minor) error is this pattern:
{code:java}
catch (IOException e) {
logger.error("Couldn't persist core properties to {}: {}", propfile,
e.getMessage());
}
{code}
Two things:
* I almost always pass the exception (variable {{e}} here) to the logger. Or
in other cases involving throwing different exceptions, the parallel is
forgetting to pass the exception as the cause. Was not doing this intentional?
* To put the details of the exception in the logged string, I suggest
e.toString() as it includes the class as well as the message. Forgetting to do
this can be confusing, like for example if you get a FileNotFoundException
where the class name itself is key to understanding what the problem is, just
as much as the file name (in the message) is.
> Use NIO2 APIs in core discovery
> -------------------------------
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
> Issue Type: Improvement
> Reporter: Alan Woodward
> Assignee: Alan Woodward
> Fix For: 5.4
>
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using
> java.io.File and friends, which have all sorts of drawbacks with regard to
> error handling and reporting. We've been on java 7 for a while now, so we
> should use the nio2 Path APIs instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
