Hi, On Sat, Sep 21, 2013 at 10:25 AM, Remi Forax <[email protected]> wrote: > On 09/20/2013 07:55 PM, Eamonn McManus wrote: >> >> > yes and no, >> > it depends how your RPC framework map errors because if you send an >> > Optional >> > and then throw an exception in the client you will not have a meaningful >> > stack trace. >> >> I don't understand what this means. Concretely, why would you not want >> Optional<Something> to be a valid return type of an RMI method? > > > Hi Éamonn, > yes, returning an Optional for a service means that you may return null > which is usually a bad practice, > given the overhead of being over the wire, it's usully better to throw an > exception with a meaningful error message.
Like Éamonn, I don't follow your reasoning. "Usually a bad practice", "usually better to throw" seem your opinions, and seem weak to base such an (important) decision on opinions only. Do you have more important insights that we're missing ? Does not throwing an exception via RMI have at least the same or even greater overhead than returning Optional ? Did you measure the overhead that retuning a serializable Optional produces ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
