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