CODEWITHSUNDEEP
scalatry-catchexpression
ib84
ib84

Reputation: 675

try not a full blown expression?

Try/catches can be used like an expression, so:

 scala> try { 3 } catch {case _ => 0}
 res52: Int = 3

Also: 

scala> try { 3 } catch {case _ => 0} finally try {println("side effect")} catch { case _ => println("catching side effect") } 
side effect
res50: Int = 3

so why not:

 scala> try { 3 } catch {case _ => 0} + 4
 <console>:1: error: ';' expected but identifier found.
   try { 3 } catch {case _ => 0} + 4

or why not:

scala> try { 3 } catch {case _ => 0} match {case 3 => "hi"}
<console>:1: error: ';' expected but 'match' found.
   try { 3 } catch {case _ => 0} match {case 3 => "hi"}

My goal is a function definition like this:

def transact[T](code : Unit => T):T = 
   try {startTransaction; Right(code)} 
     catch {case t:Throwable => Left(t)} 
   finally try {endTransaction} 
     catch { case e:... if ... => throw e}  
 match  {
   case Right(e) => e
   case Left....
 }

Of course I could just store the try/catch in a val and match the val:

 def transact[T](code : Unit => T):T = 
 {
   val transa = try {startTransaction; Right(code)} 
     catch {case t:Throwable => Left(t)} 
   finally try {endTransaction} 
     catch { case e:... if ... => throw e}  
transa match { 
 case ...
}
}

but then it no longer is a single expression, and I need to wrap in another {} which - please corect me if I'm wrong- means another layer of function object wrapping aka indirection, at a performance critical place.

So, is there a way to use try as a full expression and avoid this indirection?

thanks

Upvotes: 2

Views: 308

Answers (1)

jsalvata
jsalvata

Reputation: 2205

It's a scala grammar issue -- just add parenthesis to turn the try/catch block into a SimpleExpr so you can continue operating on it:

scala> (try { 3 } catch {case _ => 0}) + 4
res1: Int = 7

scala> (try { 3 } catch {case _ => 0}) match {case 3 => "hi"}
res2: java.lang.String = hi

As usual, curly and round brackets are (mostly) interchangeable -- your target code will look nicer (imo) with curly brackets.

No idea about indirections -- you would need to look at the compiled bytecode for that -- but I doubt it will make a difference.

For a full explanation on the grammar issue (which is not exactly an operator precedence issue as I initially believed), see: https://stackoverflow.com/a/7530565/178551

Upvotes: 7

Related Questions