Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

slideshare.net

Post reply on HN
Print view View original

51–60 of 72 posts

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

#51

Post by kstenerud »

What you really want is something along the lines of:

    void myMethod()
    {
        disposable File myFile = new File(somePath);

        // ... do stuff with the file

        // "disposable" modifier causes myFile to be
        // forcibly destroyed upon leaving scope for any
        // reason (except if the disposable object itself
        // is returned from the method).
    }
An idiom designed specifically for the purpose of resource management would make for a far cleaner implementation than shoehorning an existing mechanism.

You'd probably also need to add checking for references to the object by still-living objects (i.e. objects not eligible for gc). If any live object has a reference to the disposable object, its "disposable" status gets removed. Similarly, returning the disposable object from the method also strips its "disposable" status. It would add extra processing at the end of the scope level, but generally methods that create/use resources don't need to be lightning fast anyway.

You could even add the "disposable" modifier to class definitions, making all instances of that class disposable by default (and thus destroyed unless referenced or returned).

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

#52

Post by JulianMorrison »

munificent wrote: post #50
JulianMorrison wrote: post #6

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.

Go's multiple return at least makes that simpler than C, you don't have to remember to check a global error code, and there are no magic return codes multiplexed with the expected response.

But the fundamental difference is that if you have code that does

    a()
    b()
    c()
then you can guarantee that a() will be executed, then b(), then c(). And if there are any branches in case of errors, they will be explicit. Exceptions surround every statement with the possibility of an unannounced exit.

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

#53

Post by lloeki »

munificent wrote: post #49
orangecat wrote: post #23

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.

Then implement '__del__' which will e.g release the lock on garbage collection, and use 'with' when you want to be deterministic about it.

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

#54

Post by aliguori »

kstenerud wrote: post #51

What you really want is something along the lines of: void myMethod() { disposable File myFile = new File(somePath); // ... do stuff with the file // "disposable" modifier causes myFile to be // forcibly destroyed upon leaving scope for any // reason (except if the disposable object itself // is returned from the method). } An idiom designed specifically for the purpose of resource management would make for a far cle…

It's not so easy because what happens if you have code like this:

  static File globalFile;
  
  void register_file(File aFile)
  {
      globalFile = aFile;
  }
  
  void myMethod()
  {
      disposable File myFile = new File(somePath);
  
      register_file(myFile);
  }
If you answer, "add referencing counting", reference counting isn't perfect because you can create cyclic references.

The only reason RAII works in C++ is because you can refer to an object by value and separately by reference. You can create stack-based objects that have a defined scope.

You really can't have this in a language that always treats objects only by reference.

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

#55

Post by kstenerud »

aliguori wrote: post #54
kstenerud wrote: post #51

What you really want is something along the lines of: void myMethod() { disposable File myFile = new File(somePath); // ... do stuff with the file // "disposable" modifier causes myFile to be // forcibly destroyed upon leaving scope for any // reason (except if the disposable object itself // is returned from the method). } An idiom designed specifically for the purpose of resource management would make for a far cle…

It's not so easy because what happens if you have code like this: static File globalFile; void register_file(File aFile) { globalFile = aFile; } void myMethod() { disposable File myFile = new File(somePath); register_file(myFile); } If you answer, "add referencing counting", reference counting isn't perfect because you can create cyclic references. The only reason RAII works in C++ is because you can refer to an obje…

My answer would be to create a shortcut in the existing reference system of the gc. Invoke a subset of the gc which checks a reduced list of object references made from that scope or deeper.

Reference counted systems only work if you don't create cyclic (strong) references, so that argument is moot. In fact, reference counted systems can deal with resource objects easily so long as the compiler/interpreter ensures that pending autoreleases are executed when unwinding the stack during an exception.

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

#56

Post by yonilevy »

The majority of the comments seem to be negative, yet many of them reflect a misunderstanding of RAII. I've argued the exact argument the author does many times before and got similar responses, it seems to be hard to convey the power of RAII to people who haven't practiced it before. The meaning of RAII is that you can tie a resource to the lifetime of an object, in an environment where the object gets destroyed deterministically. There are two practical uses: 1) You can hide the fact an object is holding a resource from users of the object. 2) You can leverage the power of objects within the language and apply it to resources. The part regarding languages allowing something that might look similar with syntactic sugar didn't convey it's message very well. The syntactic sugar other languages are introducing is great on its own, but it's inferior to the object based approach since it doesn't allow (1) nor (2). It's annoying that languages with garbage collection support have gained a lot of attention solely due to the fact that you don't have to worry about freeing memory, while languages with RAII support in which you basically don't have to worry about freeing any resource, got none.

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

#57

Post by ezy »

munificent wrote: post #49
orangecat wrote: post #23

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.

Likewise for auto_ptr, but he glosses over that.

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

#58

Post by edsrzf »

munificent wrote: post #50
JulianMorrison wrote: post #6

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.

Yes, but it's much easier to recognize ignored error codes than ignored exceptions:

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...

In Go, it's even easier to recognize ignored error codes because you tend to have fewer levels of indentation and sometimes an explicit "_" when you're discarding a return value.

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

#59

Post by gerner »

lloeki wrote: post #53
munificent wrote: post #49

Earlier quoted context omitted.

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.

Then implement '__del__' which will e.g release the lock on garbage collection, and use 'with' when you want to be deterministic about it.

But that brings up the non-deterministic point the author makes. You can't know when the object will be garbage collected. It could be a long time from now, or never if you get an unexpected deadlock.

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

#60

Post by shasta »

ezy wrote: post #57
munificent wrote: post #49

Earlier quoted context omitted.

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.

Likewise for auto_ptr , but he glosses over that.

How do you figure? There isn't an implicit conversion from auto_ptr to T *.
Post reply on HN