[
https://issues.apache.org/jira/browse/SOLR-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184359#comment-13184359
]
Erick Erickson edited comment on SOLR-3022 at 1/11/12 8:49 PM:
---------------------------------------------------------------
Mark:
You're right, this is totally related. I think it would be better to
conditionally set the logged value based on the current value when passing in a
throwable. How about if James and I handle the SolrException bit? Or are you
about to check in 2191? and we can close this one?
James:
I had the same problem. There's another c'tor just above that one that looks
like this:
{code}
public SolrException(ErrorCode code, String msg, Throwable th) {
this(code,msg,th,true);
}
{code}
That's the actual one being called in the RequestHandler case.
I'm not a huge fan of zillion c'tors, perhaps all we really need is a comment
for this c'tor
{code}
public SolrException(ErrorCode code, String msg, Throwable th, boolean
alreadyLogged)
{code}
that the msg can be null? In fact, it looks like both the msg and th parameters
can all be null as far as the base java classes are concerned, so I wonder if
we wouldn't be better off just making those c'tors all use the same one, like:
{code}
public SolrException(ErrorCode code, String msg) {
this(code, msg, null, false);
}
public SolrException(ErrorCode code, String msg, boolean alreadyLogged) {
this(code, msg, null, alreadyLogged);
}
public SolrException(ErrorCode code, String msg, Throwable th, boolean
alreadyLogged) {
super(msg, th);
this.code = code.code;
logged = alreadyLogged;
}
public SolrException(ErrorCode code, String msg, Throwable th) {
this(code, msg, th, (th instanceof SolrException) ? ((SolrException)
th).logged : false);
}
public SolrException(ErrorCode code, Throwable th) {
this(code, null, th, (th instanceof SolrException) ? ((SolrException)
th).logged : false);
}
{code}
was (Author: erickerickson):
Mark:
You're right, this is totally related. I think it would be better to
conditionally set the logged value based on the current value when passing in a
throwable. How about if James and I handle the SolrException bit? Or are you
about to check in 2191? and we can close this one?
James:
I had the same problem. There's another c'tor just above that one that looks
like this:
public SolrException(ErrorCode code, String msg, Throwable th) {
this(code,msg,th,true);
}
That's the actual one being called in the RequestHandler case.
I'm not a huge fan of zillion c'tors, perhaps all we really need is a comment
for this c'tor
public SolrException(ErrorCode code, String msg, Throwable th, boolean
alreadyLogged) {
that the msg can be null? In fact, it looks like both the msg and th parameters
can all be null as far as the base java classes are concerned, so I wonder if
we wouldn't be better off just making those c'tors all use the same one, like:
public SolrException(ErrorCode code, String msg) {
this(code, msg, null, false);
}
public SolrException(ErrorCode code, String msg, boolean alreadyLogged) {
this(code, msg, null, alreadyLogged);
}
public SolrException(ErrorCode code, String msg, Throwable th, boolean
alreadyLogged) {
super(msg, th);
this.code = code.code;
logged = alreadyLogged;
}
public SolrException(ErrorCode code, String msg, Throwable th) {
this(code, msg, th, (th instanceof SolrException) ? ((SolrException)
th).logged : false);
}
public SolrException(ErrorCode code, Throwable th) {
this(code, null, th, (th instanceof SolrException) ? ((SolrException)
th).logged : false);
}
> AbstractPluginLoader does not log caught exceptions
> ---------------------------------------------------
>
> Key: SOLR-3022
> URL: https://issues.apache.org/jira/browse/SOLR-3022
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: James Dyer
> Assignee: Erick Erickson
> Priority: Trivial
> Fix For: 4.0
>
> Attachments: SOLR-3022.patch, SOLR-3022.patch
>
>
> I was setting up a new 4.x environment but forgot to put a custom Analyzer in
> the classpath. Unfortunately AbstractPluginLoader didn't log the exception
> and it took a long time for me to figure out why "No cores were created".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
