-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jason,
On 2/13/19 07:39, Jason Gerlowski wrote: > Hey Chris, > > Unfortunately I think you covered the main/only options above. > > HTTP status code isn't the most useful, but it's worth pointing > out that there are a few things you can do with it. Some status > codes are easy to identify and come up with a good message to > display to your end user e.g. 403 codes. But of course it doesn't > do anything to help you disambiguate 400 error messages you get. > > Error handling has always been one of SolrJ's weak spots. One > thing people have suggested before is adding some sort of enum to > error responses that is less ambiguous and easier to interpret > programmatically, but it's never been picked up. A bit more > information on SOLR-7170. Feel free to vote for it or chime in > there if you think that'd be an improvement. I've added some comments and a proposed fix that meets *my* needs, but I want to make sure that it will be useful for others (and not just my specific use-case). Thanks, - -chris > On Tue, Feb 12, 2019 at 5:09 PM Christopher Schultz > <ch...@christopherschultz.net> wrote: >> > Hello, everyone. > > I'm trying to get some information about a (fairly) simple case > when a user is searching using a wide-open query where they can > type in anything they want, including field-names. Of course, it's > possible that they will try to enter a field-name that does not > exist and Solr will complain, like this: > > org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: > > Error from server at http://localhost:8983/solr/users: undefined field > bad_field > > (This is what happens when I search my user database for > "bad_field:foo" .) > > What is the best way to discover what happened on the server -- > from a code perspective. I can certainly read the above as a human > and see what the problem is. But my users won't understand > (exactly) what that means and I don't always have English-language > searching my user databas e. > > Is there a way to check for "was the error a bad field name?" and > "what was the bad field name (or names) detected?" > > I looked at javadoc and saw two hopefuls: > > 1. code -- unfortunately, this is the HTTP response code > > 2. metadata -- unfortunately, this just returns > {error-class=org.apache.solr.common.SolrException,root-error-class=org .a > > pache.solr.common.SolrException}, > which is already obvious from the exception type. > > Is there something in SolrJ that I'm overlooking, here, or am I > limited to what I can parse out of the exception's "getMessage" > string? > > Thanks, -chris > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxkPP8ACgkQHPApP6U8 pFiWkg/+Jd9kHBUc0dYPw9EqkiqjzKDc+/adtERK1TktD/GxYoJaXoKwkNeSt+5C nOysBDwPoPBZELKmCQVDyyyIKrGfSYw2Pva0fDuMr1fKNoazf6I68/5BusjNf5iL ETkPuCtGuV6fmETGnK9xLFKE41tTO2u32erWnCcxbBPC858qNhafYfO1UZ3lzjuj kvuV81RESL4LQvbfx98FKxhgiHJGCV9maY4xFGQeNpI0nc3btnneAGfqUIBxJdhk RT97PdMF1yZ37aLx4H4wUTtey8hAvJhHSpDg1fw+UDNoGXcefpTwh+KQMqK5D3Cg QRLzdbzu2BR14saV2tkJ+lKbt0zvurYgOJ2J2CaCz2o44n0P82ll3hCnUCV8WfYW G70iKi8+8y73jMCOYf5hPO3O5uUJXg3dpGjgaRHHzkoOks2A+3QEWlX0CWEyoO4U Zg2avKpZNgHj6I5TxyiHD4EkhU3/e3GHbB4neUyvU36zpC6+g54a3CM7HoxWBTUn NtU2C7jDHJozUnn1S3IGOIdwv5CJ7rJNfgp+m/BOw9xuF1g/Rt7QG68J5KK0/JQE IL68zAQzWX/1KubIT3Ro5AD/2tR8CKXsCv72U8CdpjSQFFnV+6rFAvS2M7e1D6dm Lj3yRS4EcKQEgYUKltyWGX2GqnLENGLOUa2wd3aiJY7kiOdNgrA= =75gr -----END PGP SIGNATURE-----