Shouldn't Optional be Serializable?
simone.bordet at gmail.com
Sat Sep 21 12:35:59 PDT 2013
On Sat, Sep 21, 2013 at 10:25 AM, Remi Forax <forax at univ-mlv.fr> 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
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 ?
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
More information about the jdk8-dev