[rabbitmq-discuss] Java RabbitMQ API bug in response.getHeaders()?

[Tony Garnock-Jones]

On 27 October 2011 12:23, Mario Leyton <mleyton at niclabs.cl> wrote:

> If there are no headers, it doesn't matter why, a good API should always
> return an empty Map o List and not null because it contaminates the API
> user's code.


It may do so for Java. Other languages do things like this differently.
AMQP is language-neutral, and has its own semantics. The API should make it
easy for the user to work with AMQP semantics, and should not, for example,
lull the user into a false sense that all the world is a Java program. If a
sender sent a message with a missing username header, for instance, that
should be hard to misinterpret as the sender having sent a message with an
empty-string username header. IMO, the same applies to maps, integers,
booleans, timestamps etc. (I'm not even sure what a sensible
"default"/"missing" value for a timestamp would be.)

You're right that we could do what the C library does, and use a separate
flag, but I believe this would make it more likely that subtle
interoperability issues would arise. At least with the NPE you get rapid
feedback that someone isn't following the communication contract; either
the local Java code, in which case adding a null check lets you conform to
the language being spoken by the remote party, or the remote party's code,
in which case you can either choose to work around the difference locally
or get the remote party to change. Papering over the difference at the API
level masks the underlying problem.

If you are working in an all-java environment, a good choice for your code
might be to abstract away the difference between a missing map and an empty
map.

Regards,
  Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111027/3601f689/attachment.htm>