4 ms·

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

superkarn 15y ago
You can use it to suppress exceptions.
vorg 15y ago
> 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.
- mattgreenrocks 15y ago
  > 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?
  - ajuc 15y ago
    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.
    - scott_s 15y ago
      This is an accepted idiom in C++, but I don't think it makes much sense in Java, since there are no destructors.
  - strictfp 15y ago
    And why not pick java simpler nested scope syntax '{ //doit }'?
  - vorg 15y ago
    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.
    - Torn 15y ago
      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.
      - vorg 15y ago
        You can do that in Java but not in Groovy unless you write tr:{ //... }
    - scott_s 15y ago
      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.
  - deleted 15y ago
    [deleted]

You can use it to suppress exceptions.

vorg 15y ago

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

mattgreenrocks 15y ago
> 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?
- ajuc 15y ago
  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.
  - scott_s 15y ago
    This is an accepted idiom in C++, but I don't think it makes much sense in Java, since there are no destructors.
- strictfp 15y ago
  And why not pick java simpler nested scope syntax '{ //doit }'?
- vorg 15y ago
  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.
  - Torn 15y ago
    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.
    - vorg 15y ago
      You can do that in Java but not in Groovy unless you write tr:{ //... }
  - scott_s 15y ago
    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.
- deleted 15y ago
  [deleted]