[
https://issues.apache.org/jira/browse/SOLR-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028240#comment-13028240
]
David Smiley commented on SOLR-2191:
------------------------------------
Ehh... I kind of like the notion but wether it is kept or not, I think a
general error/exception strategy needs to be devised.
In code I write, I tend to almost never log exceptions; I let them get to the
highest possible point to ensure they are logged there once, which is usually
one place. Beforehand I might catch an exception to do a log.error() to
provide some context and then rethrow the exception. I also wrap with
RuntimeExceptions.
An alternative is to log exceptions early (with contextual error message), and
then rethrow but don't log it higher up (e.g. earlier up) the stack. But how
can that early point know the exception has been handled? It can't generically
know making your suggestion of "fix those code paths to be less chatty"
problematic. Perhaps our code will always assume that we logged an exception
before wrapping it in SolrException right before we throw them. I think that's
a reasonable policy and wouldn't require an alreadyLogged flag.
> Change SolrException cstrs that take Throwable to default to
> alreadyLogged=false
> --------------------------------------------------------------------------------
>
> Key: SOLR-2191
> URL: https://issues.apache.org/jira/browse/SOLR-2191
> Project: Solr
> Issue Type: Bug
> Reporter: Mark Miller
> Fix For: Next
>
> Attachments: SOLR-2191.patch
>
>
> Because of misuse, many exceptions are now not logged at all - can be painful
> when doing dev. I think we should flip this setting and work at removing any
> double logging - losing logging is worse (and it almost looks like we lose
> more logging than we would get in double logging) - and bad
> solrexception/logging patterns are proliferating.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
