On Thu, 23 Oct 2014 11:56:57 GMT, Sönke Ludwig wrote:
Well, I strongly disagree with the general rejection of exceptions, because IMO bad performance of throwing an exception is a bug, rather than a systematic issue. I also thought that most of it has already been fixed (apart from requiring a GC allocation per exception).
However, of course it's correct that exceptions are the wrong tool for success codes.
The problem with exception is the same as the one with GC: it's a good tool that suffers from bad performance.
However, there is no conceptual difference between using the return value or an out parameter w.r.t. the client side.
[...]
I think using semantic attributes (à la
@createsResource) is the most generally useful and clean way. A return value based approach still has the issue that it leaks very HTTP specific information to the interface. At least for most cases I'd like to avoid that, but it should be a good additional tool to have for those rare situations where you need more control.
Do you have a code example of how this could work ? Some methods could return unspecified amount of codes, i.e. ranging from 200 to 204, which could depends on runtime parameter.
I however agree that an HTTP agnostic way would be better.