Live data from Hacker News

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

mail.openjdk.java.net

51–60 of 81 posts

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

#51
post #46

Earlier quoted context omitted.

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

Can you expand on why would you like to get rid of checked exceptions?

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 propagate up the call stack by default if you don't do anything, making it harder for people to write bad exception handling code.

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

#52
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…

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

> the Groovy developers

Probably just one of them.

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

#53
post #46

Earlier quoted context omitted.

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

Can you expand on why would you like to get rid of checked exceptions?

They tend to force you to handle an exception at the wrong level. If you handle them correctly you still have to catch and wrap them at a low-level to not leak an implementation detail in methods signatures. IDE tend to be overly specific on the type of exceptions a method can rise when autofixing methods decls.

In the end you write boilerplate and fight the IDE.

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

#54
post #46

Earlier quoted context omitted.

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

Can you expand on why would you like to get rid of checked exceptions?

Because a huge proportion of the time there's nothing useful that you can actually do when you catch an exception, other than print the stack trace and exit. And because people are forced to catch the exception instead of letting it bubble up and stop the program, half the time they just swallow it and ignore it, which is even worse.

A decent roundup of some of the arguments for and against: http://www.ibm.com/developerworks/java/library/j-jtp05254/in...

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

#55
post #46

Earlier quoted context omitted.

Can you expand on why would you like to get rid of checked exceptions?

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.

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

#56

Earlier quoted context omitted.

I think stating it that way trivializes the amount of work that _has_ gone into lambdas. There's been a lot of other, more fundamental things discussed over that 2-3 year period about their implementation; way more than syntax.

What in particular? (Java isn't my primary language, so I haven't been following this.) Do you mean about how lambdas are implemented from a bytecode standpoint, or other types of issues?

Yes, to some extent there were debates about how the implementation would work, but also about how they would interact with all the various other features of Java, most of which were not constructed with lambdas in mind: generics, exceptions, inheritance, and so on, not to mention lots of fights over the syntax.

For instance, there was a long battle over whether () would be enough to invoke a lambda, or whether some sort of apply() or invoke() or .() method would be required, and a lot of the problems with () come down to differences between the way fields and methods are inherited in Java, esp. w.r.t. shadowing. I don't even know how it all came down, but it gets nasty, a lot of this stuff just wasn't designed with lambdas in mind.

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

#57
post #46

Earlier quoted context omitted.

Can you expand on why would you like to get rid of checked exceptions?

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…

I like checked exceptions because you can't not deal with the error condition. Swallowed exceptions is a code smell that any half-decent developer will notice, whereas failing to check for some return value is much more subtle. Java allows you to have both, since you can design your exceptions as unchecked, or rethrow a checked exception wrapped in a runtime exception.

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

#58
post #35

Earlier quoted context omitted.

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

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

[deleted]

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

#59

Earlier quoted context omitted.

Getting rid of something is always harder than adding it later.

I don't think this is the case here. The question isn't whether you "add" or "remove" something. The question is whether the old programs will still work or not. If I understand checked exceptions correctly, removing them will only allow more programs to compile. The old ones will still be valid as their (now optional) try-catch/finally blocks won't go anywhere.

throws RuntimeException and try / catch around RuntimeException would still be valid, so I can't see how changing all checked exceptions to runtime shouldn't affect the flow of the code.

If users wanted to they could declare 'throws TheirParticularRuntime' all the way up the stack and it would work like checked exceptions, right?

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

#60
post #50

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…

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.

Post reply on HN