scala.util.Try is syntactic sugar for Java checked exceptions

[Scott Shipp]

Apologies up front for the sensational headline. I have a colleague who thinks this. Not only have I pointed out that they don't have equivalent functionality (scala.util.Try does more) but also that the monadic error checking approach pre-dates Java's try / catch expression. Would love to hear other thoughts as well, even from anyone else who thinks Try is syntactic sugar.

[Bardur Arantsson]

On 2016-09-30 20:21, Scott Shipp wrote:
> Apologies up front for the sensational headline.

Then maybe you shouldn't have used it? ... but then you got at least me
to respond, so perhaps it achieved its purpose.

> I have a colleague who thinks this.

Your colleague is Not Even Wrong(TM).

> Not only have I pointed out that they don't have equivalent
> functionality (scala.util.Try does more) but also that the monadic error

> checking approach pre-dates Java's try / catch expression.. Would love

> to hear other thoughts as well, even from anyone else who thinks Try is
> syntactic sugar.

This is a messy paragraph.

All "Try" does is encapsulate "possible" failure. It says *nothing*
about exactly *which* exceptions may occur... which is the *whole*
purpose of checked exceptions in Java.

Given the confused nature of your last paragraph I'm not sure if *you*
*actually* understand the nature of checked exceptions. (Or maybe I'm
not understanding your phrasing.)

I'm not sure what to say other than that.

Regards,

[Naftoli Gugenheim]

I think the question is, what is the meaning of "syntactic sugar"?

I think the correct definition, at least as used in scala, is a higher level syntax that the compiler applies a well-defined, mechanical transformation to, resulting in code that you could have written yourself but doing so would be less "sweet" for whatever reason.

If your colleague agrees with that definition then all you have to do is demonstrate that decompiling code written with Try does not contain the equivalent catch blocks or throws annotations.

 

However it's possible your colleague doesn't even mean that, but is speaking very imprecisely and simply means "Try is used for roughly the same objective as checked exceptions in Java, namely having compiler knowledge that you have a possible exception," in which case you may not even disagree...

On Fri, Sep 30, 2016 at 2:21 PM Scott Shipp <nore...@myway.com> wrote:

Apologies up front for the sensational headline. I have a colleague who thinks this. Not only have I pointed out that they don't have equivalent functionality (scala.util.Try does more) but also that the monadic error checking approach pre-dates Java's try / catch expression. Would love to hear other thoughts as well, even from anyone else who thinks Try is syntactic sugar.

--

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/d/optout.

[Lutz Huehnken]

It seems there a at least two schools of error handling: "Errors are data" vs. "Errors should be handled out of band in a parallel process".

The "errors as data" school will say throwing an exception results in a side effect and breaks referential transparency. So if you want to indicate an error occurred, you should express it in your return type, e.g. use Either or Try. I think the "red book" argues in favor of this, or this blog post: http://underscore.io/blog/posts/2015/02/13/error-handling-without-throwing-your-hands-up.html

Now what your friend is probably saying, and Will Sargent phrased it well in https://tersesystems.com/2012/12/27/error-handling-in-scala/ : "With Try, exceptions must be either returned or handled by each method in the chain, just like checked exceptions." 

Is that what we want? Is the call site of a function necessarily the right place to handle errors? In Akka and Erlang world, error handling is considered a concern that should be handled outside of your domain code, by supervision - "Errors should be handled out of band in a parallel process" is quoted from this tweet: https://twitter.com/joeerl/status/740245740396654592

I'm a fan of the supervision approach, but how does it translate to "normal", non-actor code? This is a personal preference, and also possibly a temporary one, I'm ready to be convinced otherwise: Throwing an unchecked exception is a bit closer to the "out of band" idea as it at least let's you decide where in the call chain you'd like to handle it. Try as a return type on the other hand forces the caller (and each caller in the chain) to handle it, and because of this does feel very much like using checked exceptions, which I dislike.

[Oliver Ruebenacker]

     Hello,

  In Java, a checked exception is an exception that is of type Exception but not RuntimeException (the idea being that these are the ones we can and therefore should recover from). Whenever such an exception is thrown, it must be either caught within the same method or the method must be marked as throwing that type of exception. If a method is marked as throwing a type of exception, then any calling method must either catch that particular type of exception or otherwise be itself marked as throwing that exception (as the exception will fly through). An overriding method cannot throw more than the method it overrides, but it can throw less.

  So, ideally, you can rely on the exception either being caught somewhere or the main method is marked as throwing it.

  Scala has no equivalent to checked exceptions in the sense that you can not force a caller to handle any particular type of exception thrown. You can return a Try, which makes it clear to the caller that exceptions are to be expected, but you a Try itself does not tell you which type of exceptions can occur and does not force anything.

  Checked exceptions are controversial, because creating exceptions involves generating a stack trace, which is expensive and there is usually no need to know the stack trace if it is caught.

 It would be awesome if the compiler would support something that combines the good parts of Exception and Try and leaves out the bad parts. A type like "A throws B" that is treated like A until an exception occurs, and then becomes a B, skipping all A operations until a catch operation.

     Best, Oliver

--

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/d/optout.

--

Oliver Ruebenacker

Senior Software Engineer, Diabetes Portal, Broad Institute

[Kevin Wright]

It’s not the same at all.

You’re discussing here the sequence of events, at runtime, in handling an exception.  But that’s not the only consideration, you also need to think about what happens to the “flow” of types at compile-time.

Checked exceptions form a “shadow” type system, external to the declared signature of the method in question, a half-way house between static and dynamic typing, with the flaws of both paradigms and the benefits of neither.  `Try` still takes the error “out of band”, but not “out of signature”

Although not truly a monad, `Try` gives you almost all of the same benefits that you’d expect from monads as regards composability, and it’s a true fully-fledged member of the type system.  It can be mapped, flatMapped, filtered, sequenced, sliced & diced in ways not so readily possible with checked exceptions.  It can be abstracted away into a higher-kinder type, you can perform a semigroup combine between two Trys, and have the compiler infer for you the correct LUB exception type, you can trivially convert a Try[T] to a Future[T] (perhaps via a monad transformer) so-on and so-forth.

So no, it’s not just “syntactic sugar”, it’s not just a pretty way of wrapping an existing mechanism.  When it comes to type-level programming and certain classes of Functional Programming, these are very different beasts indeed.

--

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/d/optout.

--

Kevin Wright
mail / hangouts / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[oss.m...@gmail.com]

I think it it worth to point out that virtually every programmer starting to learn Scala having Java background will very soon ask the question what is the actual difference between checked exception and Try outside of the syntax. I'm not sure if Scala docs and books pay enough attention to explain it and provide complete picture so that reader can easily collect understanding on differences, purpose and use cases of each option.

Petr

[Viktor Klang]

Try has quite literally *nothing* to do with checked exceptions.

It's, IMHO, better explained as an on-heap version of try (which is on-stack).

On Thu, Oct 13, 2016 at 11:53 AM, <oss.m...@gmail.com> wrote:

I think it it worth to point out that virtually every programmer starting to learn Scala having Java background will very soon ask the question what is the actual difference between checked exception and Try outside of the syntax. I'm not sure if Scala docs and books pay enough attention to explain it and provide complete picture so that reader can easily collect understanding on differences, purpose and use cases of each option.

Petr

--

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/d/optout.

--

Cheers,

√

[Kevin Wright]

That’s a poor comparison

You can’t compare Try to checked exceptions in Scala… because Scala doesn’t have checked exceptions!

What you’re comparing is Try to thrown exceptions of any sort, where the key difference is that Try pulls exceptions into the signature of the method, and allows them to be handled using all the standard map/flatMap/etc tactics that you’d use elsewhere in the language.

It’s also worth comparing Either to both Try and Exceptions.  An exception isn’t automatically the best way to capture an error condition, and Either gives you the freedom to choose alternate mechanisms.  Remember that Try is a relative newcomer to Scala, and that we had Either long before Try was adopted.

[Roland Kuhn]

13 okt. 2016 kl. 12:00 skrev Viktor Klang <viktor...@gmail.com>:

Try has quite literally *nothing* to do with checked exceptions.

To elaborate: Java exceptions are checked if their type satisfies certain bounds (i.e. below Exception but not below RuntimeException). Try has no such bounds, it is the called method’s signature that determines whether failures are lifted into Try values or not. So with Scala’s Try we don’t have checked exceptions, we have checked methods.

Regards,

Roland

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

[Viktor Klang]

And more importantly, the type of the Exception is not surfacing as a constraint for the caller to satisfy.
(like try in Scala but unlike try in Java)

--
Cheers,
√