As long as the caller can get at the response headers after they catch an exception, then I think we're covered as is -- the caller catches QueryException, looks at the HTTP status using exception.getStatus(), and if it's 401, looks for the authentication scheme by pulling that response header out of the query.
-T On Thu, Oct 22, 2009 at 12:50 PM, Greg Brown <[email protected]> wrote: > >> Why not have the Query class thrown a different exception (e.g. > QueryAuthenticationException) if it couldn't authenticate? > >Why not ? Thanks for the suggestion, could be useful ... now let's see > >what say Greg on this. > > I think that's a slippery slope. Why wouldn't we then also define custom > exceptions for every HTTP error code? I think I would prefer to leave it as > is. > > >In any case, a GenericAuthentication class (or whatever name it should > >have) is missing, to solve the problem shown before, to provide a sort > >of abstraction to simplify life to coders, and also in the case a > >dialog (pivot standard or not, it's a detail) has to be shown to > >handle this situation in a simple way, like in browsers. > > > >Or is it unnecessary because I can do a Query first without > >authentication, and in case of authentication error, instance the > >right authenticator and redo the query ? > > Correct. > > >So maybe this could become a sort of factory to instance them if/when > >required ... and finally we could refactor Basic and Digest > >Authentication classes with a common base class. > > Honestly, I think this kind of code is pretty straightforward and should be > left to the application. > >
