Live data from Hacker News

Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)

slideshare.net

41–50 of 72 posts

Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)

#41

Earlier quoted context omitted.

Out of the three languages he mentions as having syntactic sugar, he was wrong only in Ruby's case. Like you said, it's not a specific syntactic sugar for Dispose pattern, unlike C#'s "using" and Python's "with".

Honest question: what's the difference between Ruby and Python/C# here?

Let's look at rst's example:

   File.open("...") do |f|
     ... stuff that might throw an exception ...
   end
The syntax you see here is for passing a block to a method. In this case, you're passing a block to File.open, which opens the file, executes your block with it and then makes sure to close the file no matter what.

In Python, you would do:

   with open("x.txt") as f:
     ... stuff that might throw an exception ...
What this does is evaluate open("x.txt"), call the __enter__ method on the resulting value (called the context guard), assign the result of the __enter__ method to f, executes the body of the with statement and makes sure to call __exit__ method of the guard.

The difference is that the syntax used in the Ruby example uses is not syntactic sugar for Dispose pattern, it's part of Ruby's syntax for working with blocks in general, whereas the syntax used in Python example is syntactic sugar meant for Dispose pattern (but can be used for other stuff too).

Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)

#42
post #36

[deleted]

.. and nonmemory resources? File handles, sockets, network connections,... ?

I wasn't refering to those resources, only what the example showed, cleanup of objects in memory.

Of course closing open connections is a must. That's day 1 stuff.

Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)

#43
post #7

...am I reading correctly that his argument for using C++/D (!) is that it's hard to remember to say this: try { mightFail(); } finally { doCleanup(); } instead of this: mightFail(); doCleanup();

Honestly, I'm not clear what he's saying, as I don't know D well. It looks like he was saying that SCOPE variables get cleaned up when leaving scope. Although if doCleanup() also does some additional cleanup, like cleaning up some associated resources that aren't scoped to this block then I think you're still screwed. Maybe someone can clarify if I'm wrong.

Any variables created in the method are cleaned up when the thread leaves the method. I've never heard of clean up being done after execution leaves a try-catch block. Does anyone know the answer to this?

Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)

#44
High-performant, world-class C++ is fairly well understood (afaik) to only use a very limited subset of C++'s features (e.g., see the JSF Coding Standard or Google Style Guide or go work for a hedge fund where low latency and high reliability is important).

The same for Java. I honor all the exceptions in the standard/platform libraries. But I see past the hype for my own interfaces. Imho, 9/10 exception classes clutter the interface. 9/10 (again for high reliability, high quality code that you want to work reliably but also be flexible enough to extend), what you want to return is a boolean (and log) for stateful methods. Meanwhile prefer stateless methods wherever possible. And generally speaking treating the JVM and Java as basically a really really high performant scripting engine (i.e., closer to JS than C; though the syntax is somewhere in between). Imho, if you can't do RAII, and you're not deterministic, you are basically a scripting language (or are in the GC family of languages, if you don't like the term 'scripting' -- I think it's cool...).

Anyway, that's how I approach it. But I don't buy into the hype of exceptions most of the time (though of course I honor whatever contract other libraries use).

Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)

#45
post #44

High-performant, world-class C++ is fairly well understood (afaik) to only use a very limited subset of C++'s features (e.g., see the JSF Coding Standard or Google Style Guide or go work for a hedge fund where low latency and high reliability is important). The same for Java. I honor all the exceptions in the standard/platform libraries. But I see past the hype for my own interfaces. Imho, 9/10 exception classes clut…

Imho, 9/10 exception classes clutter the interface.

Thats why checked exceptions are such a bad idea... Personally, I really like Go's defer, panic, recover mechanism[1] for handling exceptional circumstances.

[1] http://blog.golang.org/2010/08/defer-panic-and-recover.html

Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)

#47
I am not super familiar with all the details of Java inner classes, but why can't you get most of the way there by doing something like:

  DB.open(new Runnable() {
    public void run() {
      // ... do stuff here ...
    }
  });
You can even design your resource layers such that they can only be used this way (or are easiest to use this way).

Basically, I'm just stealing the JavaScript-y way of doing this that uses closures:

  DB.open(function() {
    ...
  });

Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)

#48
post #7

...am I reading correctly that his argument for using C++/D (!) is that it's hard to remember to say this: try { mightFail(); } finally { doCleanup(); } instead of this: mightFail(); doCleanup();

No, you're just oversimplifying his argument. It's not only "hard to remember", it also makes your code overly verbose. That, in turn, degrades its readability, making everyone else spend more time on it and making you, as the author, avoid using the pattern, which leads to writing "prettier", yet unsafe code. Then again, if "hard to remember" is meant as a euphemism for "I know I should write things this way but I r…

Bjarne Stroustrup's FAQ has an entry on why C++ doesn't have a "finally" construct: http://www2.research.att.com/~bs/bs_faq2.html#finally

I cannot remember where I saw this (which is a giant problem in itself because I can't remember the details, just that there was a gotcha...) but I read someplace that it is actually pretty easy to introduce disastrous bugs into try/finally blocks. Perhaps it had something to do with managing locks. It could have been the Go guys who said it when talking about why Go doesn't support exceptions, or perhaps it was in multicore literature (perhaps TBB talking about its RAII locking mechanism?). If anybody has any ideas what it is I'm trying to remember here, please comment. If not, well, ignore.

Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)

#49

Python's "with" statement handles this scenario: http://effbot.org/zone/python-with-statement.htm

The author is aware of that, but you have to remember to use "with". If you forget to use it, you can still have unclaimed resources.

Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)

#50

Also, Go gets this right with "defer", and with mostly deterministic error handling (panicking is not the normal way to signal an error, returning a status is).

That just pushes the problem around. You don't have to worry about forgetting to catch an exception, you have to worry about ignoring an error code.
Post reply on HN