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