Try or Try[Option]

[Filippo De Luca]

Hi,
I have a newbie question here: "Does it make sense to have a method returning Try[Option[...]]? or I should map the None case in an Exception?

The scenario I am looking to a Repository that can return None if the record is not present in the storage but the storage can also raise an exception like network exception. Maybe I'm missing the point and I should use Try only for recoverable exception?

Thanks for any clarification.

[David Miguel Antunes]

Hi Filippo,

Yes, it makes perfect sense.

Cheers,

David

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Vlad Patryshev]

Try[Option[T]] is a good thing, it reflects three kinds of outcome - error, success, no outcome.

I have a special class for this, Result[T], but yes, Try[Option[]] can replace it. The only inconvenience is that it is not a monad per se; probably it is applicative, but have to figure out.

OTOH, one could probably write something like class TryOr[T] extends Try[Option[T]] and implement the missing parts.

Thanks,
-Vlad

[Filippo De Luca]

Thanks Guys,

I know that is not monadic, and so yes it would be good to make it monadic. The same is true for Future[Option[T]] that for the same reason makes sense then.

Thanks a lot.

[Rex Kerr]

Indeed, I also have a tripartite quasi-monad, Tri, for the same kind of cases.  But it's not necessary; it just reduces the boilerplate a bit from Try[Option[T]].

  --Rex

P.S. A "quasi-monad" because where monad laws and not leaking exceptions conflict, Tri errs on the side of safety rather than monadicity.

[Vlad Patryshev]

I wonder if intuitionistic 3-valued logic could be somehow useful; it's not a big deal to implement, but it would be a big step conceptually, to drop booleanness.

Thanks,
-Vlad

[Rex Kerr]

Eh, intuitionistic 3-valued logic is isomorphic to Option[Boolean], isn't it?  Just use Option[Boolean].  The only reason I like having Tri is that I can push different conditions around easily (e.g. I can rescue this kind of failure, turn that kind of exception into this kind of error message, etc.).

  --Rex

[Rex Kerr]

Ah, yes, the Lift one is just like Try[Option[_]].  Tri is like Try[Either[_,_]].

  --Rex

On Fri, Dec 6, 2013 at 2:55 PM, David Miguel Antunes <david...@antunes.net> wrote:

The lift framework has a "tri-state" version - Box:

https://github.com/lift/framework/blob/master/core/common/src/main/scala/net/liftweb/common/Box.scala

It has a: Full an Empty and a Failure.

But it seems to me that way you loose the information of whether it means a Option[Try[...]] or a Try[Option[...]] ...

David

[Eduardo M. Cavalcanti]

> --
> You received this message because you are subscribed to the Google
> Groups "scala-user" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scala-user+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

Hi Filippo,
By coincidence I have just seen your type on video lecture 1 of week 4
of the Reactive Programming course on Coursera. Its the initial
explanation on Observables. Thanks for easing out my understanding of
the explanation. :)
Regards.

[Filippo De Luca]

You are welcome :)

On 8 December 2013 15:06, Eduardo M. Cavalcanti <eduardo.m....@uol.com.br> wrote:

On 12/6/2013 11:44 AM, Filippo De Luca wrote:

Hi,
I have a newbie question here: "Does it make sense to have a method returning Try[Option[...]]? or I should map the None case in an Exception?

The scenario I am looking to a Repository that can return None if the record is not present in the storage but the storage can also raise an exception like network exception. Maybe I'm missing the point and I should use Try only for recoverable exception?

Thanks for any clarification.

--

You received this message because you are subscribed to the Google Groups "scala-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

Hi Filippo,
By coincidence I have just seen your type on video lecture 1 of week 4 of the Reactive Programming course on Coursera. Its the initial explanation on Observables. Thanks for easing out my understanding of the explanation. :)
Regards.

--

You received this message because you are subscribed to the Google Groups "scala-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

Filippo De Luca
--------------------------
Email: m...@filippodeluca.com
Web:   http://filippodeluca.com
LinkedIn: http://www.linkedin.com/in/filippodeluca

Twitter: https://twitter.com/#!/FilippoDeLuca

Gtalk: filosg...@gmail.com

Skype: filosganga80