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. But unfortunately there's nothing like this to help you out now, that I know of at least. Best, Jason On Tue, Feb 12, 2019 at 5:09 PM Christopher Schultz <ch...@christopherschultz.net> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxjRDIACgkQHPApP6U8 > pFihjBAAty32GuiOj8XnwJu55Y9tYWFoQOhNEEJEGmeh1mOv4fxj5D4Rh+7MXTJB > 7APLZ5IlNjpGMQ5ygLpfFTrLIEljn/f/a8hRslH/g+H3p/y4EJgeyvbNHaQZdkuh > HlKQ9Z/M6HK+1KGvVNB+9onU3hs7+Tct7TjWO/cZ031CPovDknsYTbOBoLW+tszS > BrsR7up0s7AOWYNkXTu8i0tf6A6nkF8+YJvml2mxNvXUCZrhHh71eL3R+v1/zGun > 6yYyGCPm5rO9Pkxq+It4Fo8pkvo3z6k65NAflMXsFcEwWaf/5OmzAjE+TrDdqfeQ > InKDsXj3w6ZOHOEWN/lq8kK1alZUP0i8MQJHpAXzlPL213joP9mN2AeNk7airIXE > hPPmUGKjOVlMDJg6ICJiPVibMjwLBiy68TQJj2DX+dMVeYTQSroPBw5VUJhrxinV > +4y6podDJ6xs+27LxfI8DZ8nGAZP/tFYMCLNIdnhOg682PfaiD3ZiDDu5dJvm871 > 7N0EK3oCkoAmQ3l7xQNtz/0nDdI5TKSOtI3KBXTY72/8dfZlSoE4kwmBh56SrKQJ > KNfT54Cj329p5qKoNBy1bKxw4GyUx0UbKQo8HyFqzK0gQHlH+23taq5IePhocW12 > uUMGSvVUnm/E+C5w3OGLJ96Y6a3aiNUORinkTJePz+sJoUbCIwY= > =Ril5 > -----END PGP SIGNATURE-----
