Shouldn't Optional be Serializable?

[Simone Bordet]

Hi,

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
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