It looks like the discussion on this is done. I'm new to this list, what is the procedure for something like this? Do I need to create a bug ticket somewhere or submit a patch?
Thanks, Pete. On Sep 21, 2013 1:38 PM, "Simone Bordet" <[email protected]> wrote: > 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 >
