On 27 October 2011 12:23, Mario Leyton <span dir="ltr"><<a href="mailto:mleyton@niclabs.cl">mleyton@niclabs.cl</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If there are no headers, it doesn't matter why, a good API should always<br>
return an empty Map o List and not null because it contaminates the API<br>
user's code.</blockquote><div><br>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.)<br>
<br>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.<br>
<br>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.<br><br>Regards,<br> Tony<br></div></div>