Hacker News Reader

Comment by vorg | Hacker News Reader

There's a JVM language out there that initially allowed try-statements without catch or finally clauses, e.g

    try{
      //for a short time only to decide
    }

But one of its despots, five years after the language was first released, changed the syntax to make a catch or finally clause compulsory, e.g

    try{
      //for a short time to decide
    }finally{}

Because I had used these standalone try-statements a lot, I had to go thru all my code and add empty finally statements to them all.

Scala, on the other hand, still allows standalone try-statements. And Scala and C# also have a better closure syntax than that language, and are more worthy to be copied by Java 8.

View on HN

  But one of its despots, five years after the language was
  first released, changed the syntax to make a catch or
  finally clause compulsory, e.g

Are you the person who believes the Groovy developers are personally working to invalidate your web tutorials so they can discredit your fork of the language?

Lest HN think I'm being ungenerous, please read http://groovy.codeplex.com/wikipage?title=Blog01 , which features similar language regarding "despots".

  Of course, Groovy also differentiates itself from Guava
  by having a dedicated language syntax, which is no doubt
  why the cartel don't want to standardize it. If it was
  standardized, they couldn't make some random blogger's
  sample code stop working by suddenly requiring all
  try-statements to have an empty finally clause.

> the Groovy developers

Probably just one of them.

Perhaps you can educate me on your better reasoning, but the only purpose I can see for an empty try block is to limit the scope of variables in a method. Quite frankly, if you find yourself in need of artificially limiting the scope of variables in a method, you've probably done too much in the method and need to refactor.

Try block are for just that, trying something you know ahead of time might fail. There's no point in using the try paradigm if you don't also intend to handle the expected failure.

If you just want to limit the scope you can just enclose your code in braces without the try. A try without the catch or finally is meaningless.

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

You can use it to suppress exceptions.

> 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.

Reply on news.ycombinator.com