[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889401#comment-13889401 ] Michael McCandless commented on LUCENE-5405: Thanks Benson, I didn't realize this would get tricky! Since success2 seems to be equivalent to succeededInProcessingField, maybe just rename success2 instead of adding a new variable? Also, could you move the infoStream output to the end of that finally clause (so we're sure to call stream.close())? Paranoia ... Otherwise it looks great. Thanks! Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0 Attachments: LUCENE-5405-4.x.patch SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889406#comment-13889406 ] Benson Margulies commented on LUCENE-5405: -- Will do. Thanks, this is exactly what sort of feedback I was looking for. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0 Attachments: LUCENE-5405-4.x.patch SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889423#comment-13889423 ] ASF subversion and git services commented on LUCENE-5405: - Commit 1563850 from [~bmargulies] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1563850 ] LUCENE-5405: backport to 4.x. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: LUCENE-5405-4.x.patch SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889424#comment-13889424 ] Benson Margulies commented on LUCENE-5405: -- rev 1563850 provides the backport. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: LUCENE-5405-4.x.patch SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889427#comment-13889427 ] ASF subversion and git services commented on LUCENE-5405: - Commit 1563853 from [~bmargulies] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1563853 ] LUCENE-5405: CHANGES.txt Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: LUCENE-5405-4.x.patch SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889432#comment-13889432 ] ASF subversion and git services commented on LUCENE-5405: - Commit 1563857 from [~bmargulies] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1563857 ] LUCENE-5405: some leftover merge info. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: LUCENE-5405-4.x.patch SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889430#comment-13889430 ] ASF subversion and git services commented on LUCENE-5405: - Commit 1563855 from [~bmargulies] in branch 'dev/trunk' [ https://svn.apache.org/r1563855 ] LUCENE-5405: changes.txt; and fix a typo of Grant's for LUCENE-5406. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: LUCENE-5405-4.x.patch SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889449#comment-13889449 ] ASF subversion and git services commented on LUCENE-5405: - Commit 1563868 from [~bmargulies] in branch 'dev/trunk' [ https://svn.apache.org/r1563868 ] LUCENE-5405, LUCENE-5406: move changes entries to 4.7. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0, 4.7 Attachments: LUCENE-5405-4.x.patch SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13888958#comment-13888958 ] Benson Margulies commented on LUCENE-5405: -- I can backport, [~mikemccand]. Is there any doc on how the project manages branches? If not, I can add some to the web site to help guide patch-offerers. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0 SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13888981#comment-13888981 ] Michael McCandless commented on LUCENE-5405: Thanks Benson. I don't know of a guide for this. Typically I'll just do this: * cd ../4x * svn merge -c NN ../trunk * (resolve conflicts, pass tests) * commit You may need to move the CHANGES entry down under 4.x (and, fixup trunk's CHANGES too, if it wasn't under 4.x to begin with). Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0 SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889050#comment-13889050 ] ASF subversion and git services commented on LUCENE-5405: - Commit 1563711 from [~bmargulies] in branch 'dev/trunk' [ https://svn.apache.org/r1563711 ] LUCENE-5405: check in the unit test, that escaped the first time. closes #21. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0 SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889051#comment-13889051 ] Benson Margulies commented on LUCENE-5405: -- Somehow the unit test escaped the prior commit. 1563711 fills it in. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0 SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889089#comment-13889089 ] Steve Rowe commented on LUCENE-5405: bq. Is there any doc on how the project manages branches? If not, I can add some to the web site to help guide patch-offerers. There is this: http://wiki.apache.org/lucene-java/SvnMerge Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0 SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889095#comment-13889095 ] Benson Margulies commented on LUCENE-5405: -- Well, svn merge did something I can't make heads or tails of, so I'm going to merge by hand. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0 SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889098#comment-13889098 ] ASF subversion and git services commented on LUCENE-5405: - Commit 1563741 from [~bmargulies] in branch 'dev/trunk' [ https://svn.apache.org/r1563741 ] LUCENE-5405: this undoes 1563711, which was the result of a cascade of confusion. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0 SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13889101#comment-13889101 ] Benson Margulies commented on LUCENE-5405: -- [~mikemccand] and [~rcmuir]: The code in the 4.x branch is more complex. I _think_ I've managed to carry the strategy across, but I'd be grateful for some skeptical eyeballs before I commit the attach patch that does the backport. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0 Attachments: LUCENE-5405-4.x.patch SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886465#comment-13886465 ] Michael McCandless commented on LUCENE-5405: Shouldn't we port this to 4.x as well? Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 5.0 SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886067#comment-13886067 ] Benson Margulies commented on LUCENE-5405: -- Am I good to commit here? Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886073#comment-13886073 ] Robert Muir commented on LUCENE-5405: - +1 Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886091#comment-13886091 ] ASF subversion and git services commented on LUCENE-5405: - Commit 1562657 from [~bmargulies] in branch 'dev/trunk' [ https://svn.apache.org/r1562657 ] LUCENE-5405: when there's an exception thrown by an analysis component, note the field name on the info stream to aid in debugging. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies Assignee: Benson Margulies SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877789#comment-13877789 ] Robert Muir commented on LUCENE-5405: - Benson: this patch looks great. I'll wait a bit for any feedback and test it out later today. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877841#comment-13877841 ] Michael McCandless commented on LUCENE-5405: +1 to include field name in the infoStream logging ... anything to help in debugging analysis problems. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[
https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875707#comment-13875707
]
Robert Muir commented on LUCENE-5405:
-
This is a lot of api overhead, a special method 'throwXYZException' and a
special exception.
I don't think its worth it myself.
Exception strategy for analysis improved
Key: LUCENE-5405
URL: https://issues.apache.org/jira/browse/LUCENE-5405
Project: Lucene - Core
Issue Type: Improvement
Reporter: Benson Margulies
SOLR-5623 included some conversation about the dilemmas of exception
management and reporting in the analysis chain. Here is a 5.0 proposal:
TokenStream.reset and TokenStream.incrementToken (and perhaps the rest)
should have a new, checked, exception in their signatures: call it
AnalysisError if you like. Unlike IOException, it will have a full set of
constructors, including the constructors that can wrap a 'cause'. Its
constructors will accept a field name.
TokenStream will have a fieldName field, accepted in a constructor argument.
(OK, this might a bit authoritarian.)
TokenStream will have:
protected void throwAnalysisException(String explanation, Throwable cause) {
throw new AnalysisException(fieldName, explanation, cause);
}
Implementors of analysis will be thus encouraged to write things like:
try {
doSomething();
} catch (IOExceptionOrWhatever e) {
throwAnalysisException(Some Explanation, e);
}
Then, situations like Solr can diagnose the field name.
Note that no information is lost here, due to the use of exception wrapping.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[
https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875709#comment-13875709
]
Robert Muir commented on LUCENE-5405:
-
This also doesnt even solve your problem, where the exception came from *within
the analysis chain*.
Analysis stuff (e.g. OffsetAttributeImpl) just has a stream of tokens. it
doesnt now about nor even have the concept of fields, and is used in cases
outside of that context too (e.g. autosuggest).
I do not think it buys anything to try to add such stuff to the analysis chain,
as thats completely unrelated to the issue. If there is going to be any context
added to exceptions, it should be done by the consumer of such streams.
Exception strategy for analysis improved
Key: LUCENE-5405
URL: https://issues.apache.org/jira/browse/LUCENE-5405
Project: Lucene - Core
Issue Type: Improvement
Reporter: Benson Margulies
SOLR-5623 included some conversation about the dilemmas of exception
management and reporting in the analysis chain. Here is a 5.0 proposal:
TokenStream.reset and TokenStream.incrementToken (and perhaps the rest)
should have a new, checked, exception in their signatures: call it
AnalysisError if you like. Unlike IOException, it will have a full set of
constructors, including the constructors that can wrap a 'cause'. Its
constructors will accept a field name.
TokenStream will have a fieldName field, accepted in a constructor argument.
(OK, this might a bit authoritarian.)
TokenStream will have:
protected void throwAnalysisException(String explanation, Throwable cause) {
throw new AnalysisException(fieldName, explanation, cause);
}
Implementors of analysis will be thus encouraged to write things like:
try {
doSomething();
} catch (IOExceptionOrWhatever e) {
throwAnalysisException(Some Explanation, e);
}
Then, situations like Solr can diagnose the field name.
Note that no information is lost here, due to the use of exception wrapping.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[
https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875710#comment-13875710
]
Benson Margulies commented on LUCENE-5405:
--
I've been frustrated for years by the coincidence that IOException lacks
constructors for 'cause', and the Lucene API is full of 'throws IOException'.
However, I only just now noticed that Java fixed this in 1.6.
So, a weaker form of this would be a subclass of IOException that can carry a
field name, and a place for TokenStream to hide a field name. Then something
like the Solr error handler could instanceof to see if there's a field name to
be had.
Given the other API changes to token stream component construction for 5.0, one
might argue that adding a ctor arg isn't so bad.
Exception strategy for analysis improved
Key: LUCENE-5405
URL: https://issues.apache.org/jira/browse/LUCENE-5405
Project: Lucene - Core
Issue Type: Improvement
Reporter: Benson Margulies
SOLR-5623 included some conversation about the dilemmas of exception
management and reporting in the analysis chain. Here is a 5.0 proposal:
TokenStream.reset and TokenStream.incrementToken (and perhaps the rest)
should have a new, checked, exception in their signatures: call it
AnalysisError if you like. Unlike IOException, it will have a full set of
constructors, including the constructors that can wrap a 'cause'. Its
constructors will accept a field name.
TokenStream will have a fieldName field, accepted in a constructor argument.
(OK, this might a bit authoritarian.)
TokenStream will have:
protected void throwAnalysisException(String explanation, Throwable cause) {
throw new AnalysisException(fieldName, explanation, cause);
}
Implementors of analysis will be thus encouraged to write things like:
try {
doSomething();
} catch (IOExceptionOrWhatever e) {
throwAnalysisException(Some Explanation, e);
}
Then, situations like Solr can diagnose the field name.
Note that no information is lost here, due to the use of exception wrapping.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[
https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875711#comment-13875711
]
Benson Margulies commented on LUCENE-5405:
--
Hmm, well, backing up. In the other discussion, you and others seemed very
unhappy with schemes of the form:
throw new SomeException(Some local explanation, someExceptionObject);
Based on your most recent remark, I don't see any other way to get around this;
my idea about storing field names is stupid, since the chains are reusable. So,
either this sort of wrapping is tolerable or not. If tolerable, I'll rewrite
this JIRA, else I'll close it.
Exception strategy for analysis improved
Key: LUCENE-5405
URL: https://issues.apache.org/jira/browse/LUCENE-5405
Project: Lucene - Core
Issue Type: Improvement
Reporter: Benson Margulies
SOLR-5623 included some conversation about the dilemmas of exception
management and reporting in the analysis chain. Here is a 5.0 proposal:
TokenStream.reset and TokenStream.incrementToken (and perhaps the rest)
should have a new, checked, exception in their signatures: call it
AnalysisError if you like. Unlike IOException, it will have a full set of
constructors, including the constructors that can wrap a 'cause'. Its
constructors will accept a field name.
TokenStream will have a fieldName field, accepted in a constructor argument.
(OK, this might a bit authoritarian.)
TokenStream will have:
protected void throwAnalysisException(String explanation, Throwable cause) {
throw new AnalysisException(fieldName, explanation, cause);
}
Implementors of analysis will be thus encouraged to write things like:
try {
doSomething();
} catch (IOExceptionOrWhatever e) {
throwAnalysisException(Some Explanation, e);
}
Then, situations like Solr can diagnose the field name.
Note that no information is lost here, due to the use of exception wrapping.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[
https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875712#comment-13875712
]
Robert Muir commented on LUCENE-5405:
-
I don't think we should change the design of the analysis stuff (adding field
names to it, add new classes or new method signatures) to support the buggy
case.
To me the question is if there should be some change to DocInverterPerField or
not: and to me thats the only place where we might change anything, because
indexwriter iterates field names for you and its true you dont have an easy
way (to my knowledge) to figure out which one it was on when it hit an issue.
Otherwise, consumers such as queryparsers etc can deal with this themselves, if
they want to add try/catch, so be it. I am sure that stuff e.g. solr is already
wrapping the exceptions there in useless SolrExceptions today.
Exception strategy for analysis improved
Key: LUCENE-5405
URL: https://issues.apache.org/jira/browse/LUCENE-5405
Project: Lucene - Core
Issue Type: Improvement
Reporter: Benson Margulies
SOLR-5623 included some conversation about the dilemmas of exception
management and reporting in the analysis chain. Here is a 5.0 proposal:
TokenStream.reset and TokenStream.incrementToken (and perhaps the rest)
should have a new, checked, exception in their signatures: call it
AnalysisError if you like. Unlike IOException, it will have a full set of
constructors, including the constructors that can wrap a 'cause'. Its
constructors will accept a field name.
TokenStream will have a fieldName field, accepted in a constructor argument.
(OK, this might a bit authoritarian.)
TokenStream will have:
protected void throwAnalysisException(String explanation, Throwable cause) {
throw new AnalysisException(fieldName, explanation, cause);
}
Implementors of analysis will be thus encouraged to write things like:
try {
doSomething();
} catch (IOExceptionOrWhatever e) {
throwAnalysisException(Some Explanation, e);
}
Then, situations like Solr can diagnose the field name.
Note that no information is lost here, due to the use of exception wrapping.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[
https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875713#comment-13875713
]
Benson Margulies commented on LUCENE-5405:
--
Yes, we're now in the same place. Does a catch/throw in DocInverterPerField
that does something like
throw new LuceneAnalysisException(Error analyzing text, fieldName,
originalException);
make life better? I think it makes life better, as I don't see much evil in
exception wrapping like this.
Exception strategy for analysis improved
Key: LUCENE-5405
URL: https://issues.apache.org/jira/browse/LUCENE-5405
Project: Lucene - Core
Issue Type: Improvement
Reporter: Benson Margulies
SOLR-5623 included some conversation about the dilemmas of exception
management and reporting in the analysis chain. Here is a 5.0 proposal:
TokenStream.reset and TokenStream.incrementToken (and perhaps the rest)
should have a new, checked, exception in their signatures: call it
AnalysisError if you like. Unlike IOException, it will have a full set of
constructors, including the constructors that can wrap a 'cause'. Its
constructors will accept a field name.
TokenStream will have a fieldName field, accepted in a constructor argument.
(OK, this might a bit authoritarian.)
TokenStream will have:
protected void throwAnalysisException(String explanation, Throwable cause) {
throw new AnalysisException(fieldName, explanation, cause);
}
Implementors of analysis will be thus encouraged to write things like:
try {
doSomething();
} catch (IOExceptionOrWhatever e) {
throwAnalysisException(Some Explanation, e);
}
Then, situations like Solr can diagnose the field name.
Note that no information is lost here, due to the use of exception wrapping.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[
https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875715#comment-13875715
]
Robert Muir commented on LUCENE-5405:
-
I dont like it being LuceneAnalysisException really: I don't see the need for a
custom class.
I think it would just be throw new IllegalArgumentException(exception from
analysis chain for field ' + field + ':, fieldName, originalException).
{quote}
I think it makes life better, as I don't see much evil in exception wrapping
like this.
{quote}
There is a lot of evil still, it changes the class type of the exception (by
wrapping it), by nesting, it makes exceptions harder to digest for the client
(lots of lucene users use the same Analyzer for every field, so the field is
just not interesting).
Remember this is *all about the buggy analyzer case*. Its not like we are
supporting a real use case here.
So that's why i said, i'm not sure about this whole idea on SOLR-5623. I'm just
not sure its the right tradeoffs.
Besides, there are possibly even less invasive solutions. If we hit an
exception from the analyzer, we could write that we hit an exception (not the
exception text, just that we hit one) for field X to the infostream in the if
(!success) case. This means there is no catch block at all! I would support
such a change today. sure its not perfectly user friendly but it has
absolutely no downsides at all, and only helps the user, and remember, this is
*all about the buggy analyzer case*. We don't need to be user friendly for
that, just safe.
Exception strategy for analysis improved
Key: LUCENE-5405
URL: https://issues.apache.org/jira/browse/LUCENE-5405
Project: Lucene - Core
Issue Type: Improvement
Reporter: Benson Margulies
SOLR-5623 included some conversation about the dilemmas of exception
management and reporting in the analysis chain. Here is a 5.0 proposal:
TokenStream.reset and TokenStream.incrementToken (and perhaps the rest)
should have a new, checked, exception in their signatures: call it
AnalysisError if you like. Unlike IOException, it will have a full set of
constructors, including the constructors that can wrap a 'cause'. Its
constructors will accept a field name.
TokenStream will have a fieldName field, accepted in a constructor argument.
(OK, this might a bit authoritarian.)
TokenStream will have:
protected void throwAnalysisException(String explanation, Throwable cause) {
throw new AnalysisException(fieldName, explanation, cause);
}
Implementors of analysis will be thus encouraged to write things like:
try {
doSomething();
} catch (IOExceptionOrWhatever e) {
throwAnalysisException(Some Explanation, e);
}
Then, situations like Solr can diagnose the field name.
Note that no information is lost here, due to the use of exception wrapping.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875724#comment-13875724 ] Benson Margulies commented on LUCENE-5405: -- https://github.com/apache/lucene-solr/pull/21 is a seemingly simple idea for how to code this. I'm off to write the test. In the mean time, I offer the PR just to show a concrete idea. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5405) Exception strategy for analysis improved
[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875726#comment-13875726 ] Benson Margulies commented on LUCENE-5405: -- Test added. It passes. I'm sure I've missed something here. Exception strategy for analysis improved Key: LUCENE-5405 URL: https://issues.apache.org/jira/browse/LUCENE-5405 Project: Lucene - Core Issue Type: Improvement Reporter: Benson Margulies SOLR-5623 included some conversation about the dilemmas of exception management and reporting in the analysis chain. I've belatedly become educated about the infostream, and this situation is a job for it. The DocInverterPerField can note exceptions in the analysis chain, log out to the infostream, and then rethrow them as before. No wrapping, no muss, no fuss. There are comments on this JIRA from a more complex prior idea that readers might want to ignore. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
