-----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-----

Reply via email to