11–20 of 21 posts
Earlier quoted context omitted.
How does structural subtyping help you implement automatic resource management?
I can define a resource management method which accepts any object which belongs to a class that provides a close method irrespective of whether that class implements close as part of an an interface or not.
lombok's @Cleanup will close anything, interface or not.
its nice but the issue for me is that it will be backwards compatible so the preJRE7 way of managing IO resources is also included , this means an even more bloated java api :-(
Earlier quoted context omitted.
I can define a resource management method which accepts any object which belongs to a class that provides a close method irrespective of whether that class implements close as part of an an interface or not.
(I had another comment here but I figured out the answer.) lombok's @Cleanup will close anything, interface or not.
InputStream in = null;
try
{
in = new FileInputStream(new File("test.txt"));
//do stuff with in
}
catch(IOException ie)
{
//SOPs
}
finally
{
try
{
if(in != null)
{
in.close();
}
}
catch(IOException ioe)
{
//can't do anything about it
}
}
InputStream in;
try(in = new FileInputStream()){
...
} catch (...){
...
}
if (x = getline()){
...
}
There's a problem with box 2. If the IOException is thrown in the stream's constructor (FileNotFoundException) then there will be a NullPointerException if we try to call close! InputStream in = null; try { in = new FileInputStream(new File("test.txt")); //do stuff with in } catch(IOException ie) { //SOPs } finally { try { if(in != null) { in.close(); } } catch(IOException ioe) { //can't do anything about it } } This…
This is just horrible. What braindead system forces you to check exceptions on closing a file handle? If everything failed silently and just produced 'null', the code would look like:
InputStream in = new FileInputStream(new File("test.txt"));
if (in) {
...dostuff...
in.close();
}
If Java had stack allocated objects there would be no need for new interfaces nor new syntax.
And when you introduce that, you have a problem of dealing with the difference between references to these inline objects: possibly on the stack or the heap, free-standing or embedded. If a reference escapes and outlives the lifetime of the object, you've created a potential dangling pointer, whereas in the normal Java or C# implementation you have at worst a semantic problem of having leaked a reference to a "closed" or disposed object. The GC won't collect it, but any operations on it will and should fail.
If you try and deal with this in the C++ way, you'll end up with far more confusion over objects passed around by reference, and objects passed around by value. Instead of the mechanism of passing being encoded by the type, it would be part of the control flow, and it would be easy to get into situations where you're working with a reference to a copy that was passed by value, and think you have a reference to the original; this is already a problem in C# to the degree that it is not recommended to create mutable value types.
TL;DR: what you suggest would create far more problems than it solves.
There's a problem with box 2. If the IOException is thrown in the stream's constructor (FileNotFoundException) then there will be a NullPointerException if we try to call close! InputStream in = null; try { in = new FileInputStream(new File("test.txt")); //do stuff with in } catch(IOException ie) { //SOPs } finally { try { if(in != null) { in.close(); } } catch(IOException ioe) { //can't do anything about it } } This…
Thanks, I didn't realize it's this bad. My only touch base with Java has been through Clojure. This is just horrible. What braindead system forces you to check exceptions on closing a file handle? If everything failed silently and just produced 'null', the code would look like: InputStream in = new FileInputStream(new File("test.txt")); if (in) { ...dostuff... in.close(); } Now, that you can grasp with one glance . I…
How is the user supposed to figure out what went wrong with the program if the program can't even convey to the user what went wrong?
Complex problems have lots of simple wrong answers.
(Your "solution" also suggests nothing about how "in.close()" is going to get called if "...dostuff..." itself throws an exception.)
Earlier quoted context omitted.
(I had another comment here but I figured out the answer.) lombok's @Cleanup will close anything, interface or not.
I took a look at lombok and it's pretty obvious from the way cleanup method names can be passed as strings that's it's using reflection. It's a bit of a nasty hack, but it works.