>On the update side of things, I think it would be nice if one could
>check the HTTP status code and if it's OK (200), don't bother XML
>parsing the body.
Do you mean 304 'Not Modified'? Agree, we should handle it in SOLR (it is
not SOAP indeed!); we should handle 'last modified', 'expiration' etc.
HTTP specs, as pointed by Hoss, allow to use 4xx codes with user-defined
entities.
There is some HTTP staff which we need to use anyway, but we should not use
HTTP codes in a core-Java parts of an application. Some code is currently
tightly coupled with such staff as
SC_BAD_REQUEST
SC_OK
SC_NOT_FOUND
This is part of JEE, and existing design looks slightly outdated: we need to
decouple such 'nice' staff:
} catch (SolrException e) {
sendErr(e.code(), SolrException.toStr(e), request, response);
}
We even _catch_ an Exception, and _rethrow_ it as 400/404 (this is also
'Exception', but in a different language)
>> 1. What is an Error?
>> 2. What is a Mistake?
>> 3. What is an application bug?
>> 4. What is a 'system crash'?
>These are not HTTP concepts. The request on a URI can succeed or fail
>or result in other codes. Mistakes and crashes are outside of the HTTP
>protocol.
Yes, I tried to mention very generic concepts and to think about
'Exceptions' in Java SE, EE, SOLR, JSON, XML, HTTP. We are always extending
java.lang.Exception without any thinking, just following patterns from
thousands of guides.
Please, have a look at
http://www.mindview.net/Etc/Discussions/CheckedExceptions
And following discussion:
http://www.bruceeckel.com/Etc/Discussions/UnCheckedExceptionComments
Some authors suggest to use unchecked exceptions. Code written in so many
books regarding try-catch-finally is suitable only for a very small
applications (usually small samples from a books)...
Thanks
