On Thu, Oct 4, 2012 at 3:42 PM, Casper Bang <[email protected]> wrote: > How do you guys handle callbacks with Void, say you really don't want > anything returned because you are only consuming, streaming or the like? > > Say you have a generified callback for extracting rows from a dataset: > > public interface RowMapper[T]{ > T map(Row row); > } > > Implementing this for the purpose of StAX streaming rather than returning > records required one to satisfy the compiler and return something. In C# I > can just omit the return line (consistent with void semantics for classic > methods). In Java however, one has to return a derivative of Void (null): > > @Override > public Void map(Row row){ > staxWriter.writeStartElement(row.getString("id")); > return null; > } > > That's not very nice looking at all. Cheating the type-system and generating > a Void instance through reflection is perhaps slightly cleaner semantically, > but very verbose. It's obviously related to type-erasure, but why on earth > didn't the Java compiler guys burn in a rule that would add a "return null" > if the signature is Void? Is there some idiom I am unaware of here that > would be nicer than returning null? > > /Casper
That's exactly how I do it, and it seems clear enough to me. The reasoning is that null is the only valid value for variable of type Void, since Void is not instantiable (without trickery). -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
