Java 8 lambda syntax decided - same as C# and Scala

Post by brlewis » Fri, Sep 09, 2011, 1:12 PM UTC

Sandman wrote: post #55

grahamedgecombe wrote: post #51

Earlier quoted context omitted.

It often leads people to write code like this: try { // do stuff } catch (TheCheckedException ex) { // ignore it } then the code continues even though it could be in a bad state if an exception did occur. It's a much better solution to let it propagate up the call stack until it can be dealt with appropriately (e.g. by ending the application, giving a 503 error on a web page request, etc.) Unchecked exceptions will p…

So add a 'throws' clause to the method in which you call the code that throws the checked exception and it will propagate upward.

Post by cbs » Fri, Sep 09, 2011, 1:42 PM UTC

ppog wrote: post #33

linuxhansl wrote: post #26

Earlier quoted context omitted.

Big deal: new Thread(new Runnable() { public void run() {doStuff();} }).start();

But for a small function (which a lambda typically is), the syntactic overhead of "new Runnable() { public void run()" swamps the actual logic. When I read this version, it's hard for my eyes to find what work is actually being done because there are so many braces and brackets and words. The big deal of lambda syntax is that it lets you focus on the code that does the work (the doStuff) instead of the adapter (the "…

Post by davedx » Fri, Sep 09, 2011, 2:01 PM UTC

brlewis wrote: post #71

Sandman wrote: post #55

Earlier quoted context omitted.

So add a 'throws' clause to the method in which you call the code that throws the checked exception and it will propagate upward.

Yes, this! The most irritating debugging I've had to do in Java code is when someone catches an exception, but fails to handle it effectively, resulting in another exception being thrown later. If you don't know how to handle it effectively, just add the 'throws' clause. It's less typing than try/catch, so I don't understand why people choose to make extra work for themselves and for me. I see a lot of comments here…

Post by scott_s » Fri, Sep 09, 2011, 2:42 PM UTC

vorg wrote: post #50

mattgreenrocks wrote: post #41

Earlier quoted context omitted.

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

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 beca…

  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")

Post by felipemnoa » Sat, Sep 10, 2011, 1:53 AM UTC

yock wrote: post #69

vorg wrote: post #30

Earlier quoted context omitted.

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…

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 po…