Earlier quoted context omitted.
It doesn't really taste like syntactic sugar though; it's a special functionality of the standard library, and you could easily get away without knowing about the Java/C-style API of keeping a file handle that has to be controlled around.
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".
Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)
31–40 of 72 posts
Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)
#32Earlier quoted context omitted.
And there actually is an idiomatic way to avoid the problem in Ruby: File.open("...") do |f| firstline = f.readline ... stuff that might throw an exception ... end If the "stuff" throws an exception, the file gets closed automatically. And while File is a library class, it's getting no special favors here --- any pure ruby library can easily implement similar APIs, and ActiveRecord's connection pool, for example, act…
Which counts as the sugar which he mentions. See also "using" in C#. These are pretty clearly design warts. WPF (C# UI library) jumps through some interesting hoops to make it look like all your resources can be properly garbage collected, but even then it tends to come back and bite you for any non-trivial application.
The argument for try...finally, using, lisp's (with-open-file...), etc. is that it makes it clear that there is 'invisible' code at the end of the block.
I suspect that is the reason for the 'scope' sugar in D. Its advantage is that it is more light-weight; its disadvantage that it does not stand out more. I guess it depends on what you think your audience can handle which is better for your case. I do not think there are many programmers that need java's very explicit try-finally because they cannot grasp e.g. what D provides, but I also have been surprised at times by the, let's say, intelligence, of programmers I met.
Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)
#33...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();
The second example should actually be class C { void mightFail() { ... } ~C() { doCleanup(); } }; C c; c.mightFail(); Anyway, I hate this slide deck so much. 1. The author's point could be made in far fewer slides. As in, like, two slides. I hate presentations that are disrespectful of the audience's time for the sake of being cute. 2. I am generally unimpressed by arguments of the form: (a) Language X has flaw Y. (b…
There is no argument against try/catch/finally, the argument is that the most common usage of try blocks is for dealing with resource management, not actual exceptions in program state. Given exceptions should be used to expression 'exceptional' program states, that is a significant downside to code readability.
Syntactic sugar like using/yield/with blocks improve the signal to noise ratio of try block usage but still rely on programmer acceptance of that idiom. Ideally, the responsibility of cleanup would be moved entirely to the class implementation rather than the consumer. C++ did this with destructors. In a managed world where maybe you don't always want an eager dispose, rather than syntactic sugar in the caller, move it to the signature of the dispose. Something along the lines of
public scoped void Dispose() { .... }
Alternatively, @Scoped or if you don't want more keywords. The topic is partly to blame but RAII is orthogonal to whether a language is garbage collected or not. It's sad that in an age where PLs are undergoing a sort of renaissance period, mention of C++ causes everyone to circle their respective wagons.
Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)
#34I think you can avoid nesting finally thus: X x = null; Y y = null; try{ x = foo(); y = bar(); yadda(x,y); } finally { if (x!=null) x.dispose(); if (y!=null) y.dispose(); }
I was thinking the same thing, but replace your finally block with, Util.dispose(x,y); ...and let that handle all the possible issues.
public void withConnection(Callback callback) { Connection connection = createConnection(); try { callback.call(connection); } finally { connection.dispose(); } }
Once Java actually gets closures it'll make this soooo much nicer.
Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)
#35The problem with this whole argument is that the author assumes that deterministic memory performance is completely necessary. It's certainly nice, but there are so many times when it just doesn't matter. While I agree that Java sucks because it makes certain very common things require extreme verbosity, worrying about garbage collection isn't all that important except in systems-level programming (which isn't done i…
Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)
#36Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)
#37Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)
#38[deleted]
Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)
#39Earlier quoted context omitted.
> [...] then you have to declare the variable to store that value outside of the try {} block That's kind of the point. The variable will only be assigned a value if mightFail returns normally. The scoping rules make it impossible to accidentally use an uninitialized variable (i.e. a variable whose first assignment was not reached due to an exception).
I take it that you're imagining a case like this: try { var result = mightFail(); } catch { handleError(); } finally { cleanup(); } print(result) // we don't want to allow this That's true, the scoping protects you from making that mistake. However, the more common case is this: try { var result = mightFail(); } finally { // let the exception bubble up cleanup(); } print(result); // this must be OK, but I can't do it…
Re: Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)
#40Earlier quoted context omitted.
The second example should actually be class C { void mightFail() { ... } ~C() { doCleanup(); } }; C c; c.mightFail(); Anyway, I hate this slide deck so much. 1. The author's point could be made in far fewer slides. As in, like, two slides. I hate presentations that are disrespectful of the audience's time for the sake of being cute. 2. I am generally unimpressed by arguments of the form: (a) Language X has flaw Y. (b…
You seem to have failed to grasp that the slides are arguing for RAII. While admittedly mildly trollish, it disparages java along with C#/ruby/python implicitly in favour of C++ only because C++ has the most 'correct' implementation of RAII. There is no argument against try/catch/finally, the argument is that the most common usage of try blocks is for dealing with resource management, not actual exceptions in program…