warning for naked try block?

[Jason Zaugg]

I just spotted one of these in the wild.

scala> try ( 1 / 0 )

java.lang.ArithmeticException: / by zero

The sublte difference to the following seems dangerous:

scala> import util.Try

import util.Try

scala> Try ( 1 / 0 )

res4: scala.util.Try[Int] = Failure(java.lang.ArithmeticException: / by zero)

I propose to issue a warning for `try` without a `catch` or `finally`. Any objections?

-jason

[Roland Kuhn]

Having written such a “let’s try … ” myself I’d definitely want to be counted in the pro camp on this one.

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

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Empowering professional developers to build amazing apps.
twitter: @rolandkuhn

[Paul Phillips]

On Sun, Feb 10, 2013 at 2:54 AM, Jason Zaugg <jza...@gmail.com> wrote:

I propose to issue a warning for `try` without a `catch` or `finally`. Any objections?

The advantage of it working as it does is that you can comment out a catch or a finally without being hassled.

I like it as an -Xlint warning, less so otherwise.

[Rex Kerr]

I think Yoda has it right on this one.

There is no try.

Evidence:

$ cat DoOrDoNot.scala
class DoOrDoNot {
  def succeed = println("I don't believe it.")
  def fail = throw new Exception("It's too big.")
  def xwing(lift: Boolean) { if (lift) succeed else fail }
  def ywing(lift: Boolean) { try { if (lift) succeed else fail } }
}

$ javap -c -private DoOrDoNot
...
public void xwing(boolean);
  Code:
   0:    iload_1
   1:    ifeq    9
   4:    aload_0
   5:    invokevirtual    #38; //Method succeed:()V
   8:    return
   9:    aload_0
   10:    invokevirtual    #40; //Method fail:()Lscala/runtime/Nothing$;
   13:    athrow

public void ywing(boolean);
  Code:
   0:    iload_1
   1:    ifeq    9
   4:    aload_0
   5:    invokevirtual    #38; //Method succeed:()V
   8:    return
   9:    aload_0
   10:    invokevirtual    #40; //Method fail:()Lscala/runtime/Nothing$;
   13:    athrow
...

The word "try" is doing precisely nothing here.  Why not make it optional?  Catch and finally simply refer to the previous block, whatever that is.  If you include the word try, it means that you want the warning.

  --Rex

[√iktor Ҡlang]

I was actually thinking the same thing, in what way is "try" even needed?

expr catch { case _: NullPointerException => whatever }

and

expr finally { … }

and

expr catch { case _: NullPointerException => whatever } finally { … }

and

expr finally { … } catch { case _: NullPointerException => whatever }


All makes sense to me and don't need try at all.

Any counter arguments?

Cheers,

√

--

Viktor Klang
Director of Engineering

Typesafe - The software stack for applications that scale
Twitter: @viktorklang

[Jason Zaugg]

On Sun, Feb 10, 2013 at 7:53 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

I was actually thinking the same thing, in what way is "try" even needed?

expr catch { case _: NullPointerException => whatever }

and

expr finally { … }

and

expr catch { case _: NullPointerException => whatever } finally { … }

and

expr finally { … } catch { case _: NullPointerException => whatever }


All makes sense to me and don't need try at all.

Any counter arguments?

People read code top to bottom, I think it's useful to mark the start of a try. Furthermore, Scala tries not to deviate from the expectations of Java programmers in matters where there isn't a clear reason to do so.

-jason 

[√iktor Ҡlang]

Using that argument, try without catch or finally must be verboten, it deviates without clear reason.

>
> -jason 

[Paul Phillips]

On Sun, Feb 10, 2013 at 11:07 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

Using that argument, try without catch or finally must be verboten, it deviates without clear reason.

Does it?

class X implements AutoCloseable {

  public void close() { }

}

public class J {

  public void foo() {

    try (X x = null) {

      return;

    }

  }

}

% javac ./J.java 

%

[√iktor Ҡlang]

Wow. Just wow.

I'll go eat some ice cream now

 

  }

}

% javac ./J.java 

%

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

[martin odersky]

On Sun, Feb 10, 2013 at 8:38 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Sun, Feb 10, 2013 at 8:32 PM, Paul Phillips <pa...@improving.org> wrote:

On Sun, Feb 10, 2013 at 11:07 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

Using that argument, try without catch or finally must be verboten, it deviates without clear reason.

Does it?

class X implements AutoCloseable {

  public void close() { }

}

public class J {

  public void foo() {

    try (X x = null) {

      return;

    }

 

Wow. Just wow.

I'll go eat some ice cream now

But that's not a try/catch/finally! It's an ARM block which is completely different despite looking similar. - Martin

 

[√iktor Ҡlang]

Indeed, but the way I formulated my argument leaves Paul's counter-argument valid. :-)

 

 

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

[Paul Phillips]

On Sun, Feb 10, 2013 at 12:23 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

Indeed, but the way I formulated my argument leaves Paul's counter-argument valid. :-)

1 klang

1 petard

1 sturdy hook

Everyone together now... HOIST!

[√iktor Ҡlang]

Don't taze me bro

 

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

[Daniel Sobral]

I can't see the point of commenting catch/finally except as a temporary measure for a test, in which case I'd like to be hassled so as not to forget to rollback the change.

 

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

--
Daniel C. Sobral

I travel to the future all the time.