Hacker News Reader

Comment by ddlatham | Hacker News Reader

What benefits does an empty try block give you? You can always use braces to separate a block without try at all.

> What benefits does an empty try block give you?

An empty try block allows us to repeat variable declarations with the same name in a long stretch of scripty-style code.

> You can always use braces to separate a block without try at all.

You can use braces in Java, but not in that language I'm talking about: it'll throw an error saying "Ambiguous expression could be a parameterless closure expression, an isolated open code block, or it may continue a previous statement; solution: Add an explicit parameter list, e.g. {it -> ...}, or force it to be treated as an open block by giving it a label, e.g. L:{...}, and also either remove the previous newline, or add an explicit semicolon ';'".

The standalone-try looked far more elegant than:

    dudlabel:{
      //do something
    }

Better for that despot to re-enable standalone try-statements in Groovy than petitioning the Java 8 designers that thin arrows look better than industry-standard thick arrows.

> An empty try block allows us to repeat variable declarations with the same name in a long stretch of scripty-style code.

Either I'm missing something here, or this is really as bad as it sounds.

I understand you want nested scopes that end before the method's scope ends, but cannot for the life of me think of a defensible code example. Why not just make them into methods?

In C++ block is often a way to ensure automatic variable destruction. This is important, because in C++ often there is important stuff going on in destructor. For example in RAII idiom.

Example:

   ...
   ...
   
   { //critical section
     QMutexLocker locksInConstructorAndUnlocksInDestructor(&mutex);
     a = doStuff(a,b,c);
     b = doOtherStuff(a,b,c);
     c = andAnother(a,b,c);

   }
   
   ..
   ..

It would be overkill to make this block a function, especially when code in critical section changes many variables.

This is an accepted idiom in C++, but I don't think it makes much sense in Java, since there are no destructors.

And why not pick java simpler nested scope syntax '{ //doit }'?

I did say scripty code. My typical scripting session from scratch starts with opening a simple editor and starting to type in code. The structure is loose, perhaps it's testing something I've written in another file in a statically-typed language. As the code evolves, I slowly give it more structure by reworking it. At some stage I MIGHT put some code into methods.

But before that stage, nested scopes are useful because I'm far less likely to pass the wrongly-named variable into a function when I'm cutting and pasting code. An example coding snippet...

    def out= new File("blah")
    try{
      def testdata= "abcdefg"
      def result= SomethingToTest(testdata, out)
      assert result == result.getSth()
    }
    try{
      def testdata= "hijk"
      try{
        def result= SomethingToTest(testdata, out)
        assert result == result.getSth()
      }
      try{
        def result= SomethingToTest(testdata)
        assert result == result.getSth()
      }
    }

If I use testdata1, testdata2, result1, result2, etc, I might forget to rename a variable after cutting and pasting, and think a test works when it doesn't.

Why not just use braces? Take all your 'try' keywords out and the scope limitations are the same.

Unless you're relying on the try {} to avoid bombing when there are assertion errors? That just seems a bad way of doing unit testing.

You can do that in Java but not in Groovy unless you write

    tr:{
      //...
    }

It sounds like you want support for a bad practice. Each of those code blocks are logically distinct tasks, and it would serve readability to factor them into functions. Further, you're abusing a language construct to do something other than its purpose.

I've never programming in Scala, so I'm going to write Python code that represents what I think is a better way of doing that kind of testing:

  def test1(data):
    result = SomethingToTest(data)
    assert result == result.getSth()

  def test2(data, out):
    result = SomethingToTest(data, out)
    assert result == result.getSth()

  out = open("blah")
  test2(out, "abcdefg")
  test2(out, "hijk")
  test1("hijk")

The problem is not that copy-pasted code may be incorrect. The problem is that you're copying and pasting code and expecting it to be correct. The way you're nesting scopes is confusing.

You can use it to suppress exceptions.

Reply on news.ycombinator.com