a criticism of java

[q_q_anonymous]

"BufferedReader foo = new BufferedReader(new InputStream(new
JavaHatesYou(new FuckOffAndDie(new
ForTheLoveOfGodLetMeJustReadTheFile(new
File("filename.txt")))))))));"


I think that speaks for itself.

Java may solve some problems that C and C++ had, but that issue
demonstrated above is just ridiculous

 

[zero]

(e-mail address removed) wrote in @z14g2000cwz.googlegroups.com:

"BufferedReader foo = new BufferedReader(new InputStream(new
JavaHatesYou(new FuckOffAndDie(new
ForTheLoveOfGodLetMeJustReadTheFile(new
File("filename.txt")))))))));"


I think that speaks for itself.

Java may solve some problems that C and C++ had, but that issue
demonstrated above is just ridiculous

BufferedReader foo = new BufferedReader(new FileReader("filename.txt"));

Of course, if you like doing it the long way... ;-)

I do feel that Sun has learned from the same master as Microsoft when it
comes to naming classes/methods. FormatFlagsConversionMismatchException
anyone?

 

[Thomas Hawtin]

"BufferedReader foo = new BufferedReader(new InputStream(new
JavaHatesYou(new FuckOffAndDie(new
ForTheLoveOfGodLetMeJustReadTheFile(new
File("filename.txt")))))))));"


I think that speaks for itself.

Java may solve some problems that C and C++ had, but that issue
demonstrated above is just ridiculous

Yeah, if the FuckOffAndDie constructor really does throw then you will
drop the love of god. And you probably don't want to be doing that.

http://jroller.com/page/tackline?entry=factoring_out_exception_handling

Tom Hawtin

 

[Chris Smith]

BufferedReader foo = new BufferedReader(new FileReader("filename.txt"));

I'd actually make that a little longer:

BufferedReader foo = new BufferedReader(
new InputStreamReader(new FileInputStream("filename.txt")));

That does exactly the same thing, but the difference is that it's more
obvious that the default character encoding is being used... and
therefore, that the code should be considered suspect in most
situations. It's not possible to use FileReader to read in a specified
encoding, and that flaw makes it worth avoiding, if you ask me.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Roedy Green]

BufferedReader foo = new BufferedReader(new FileReader("filename.txt"));

It takes quite a while to learn how to plug together all the pieces of
the java.io lego set. They lack symmetry. In the meantime, you can
crank out code using the file I/O amanuensis.

See http://mindprod.com/applets/fileio.html

Properly speaking that is not Java, but one of the Java libraries. If
you don't like it you can write your own. Sun itself has written the
nio package to try to simplify and speed it up. I think it could
easily use another round of orthogonalistation.

 

[Noodles Jefferson]

(e-mail address removed) took the hamburger, threw it on the grill, and
I said "Oh wow"...

"BufferedReader foo = new BufferedReader(new InputStream(new
JavaHatesYou(new FuckOffAndDie(new
ForTheLoveOfGodLetMeJustReadTheFile(new
File("filename.txt")))))))));"


I think that speaks for itself.

No, this does:

RandomAccessFile raf = new RandomAccessFile("P:\a\t\h", "rw");

Tadaaaaa.

Java may solve some problems that C and C++ had, but that issue
demonstrated above is just ridiculous

--
Noodles Jefferson
mhm31x9 Smeeter#29 WSD#30
sTaRShInE_mOOnBeAm aT HoTmAil dOt CoM

"Our earth is degenerate in these latter days, bribery and corruption
are common, children no longer obey their parents and the end of the
world is evidently approaching."
--Assyrian clay tablet 2800 B.C.

 

[Noodles Jefferson]

(e-mail address removed) took the hamburger, threw it on the grill, and
I said "Oh wow"...


No, this does:

RandomAccessFile raf = new RandomAccessFile("P:\a\t\h", "rw");

P:\\a\\t\\h

My bad.

Tadaaaaa.

--
Noodles Jefferson
mhm31x9 Smeeter#29 WSD#30
sTaRShInE_mOOnBeAm aT HoTmAil dOt CoM

"Our earth is degenerate in these latter days, bribery and corruption
are common, children no longer obey their parents and the end of the
world is evidently approaching."
--Assyrian clay tablet 2800 B.C.

 

[Alun Harford]

"BufferedReader foo = new BufferedReader(new InputStream(new
JavaHatesYou(new FuckOffAndDie(new
ForTheLoveOfGodLetMeJustReadTheFile(new
File("filename.txt")))))))));"


I think that speaks for itself.

Wait a second...
What are you doing with the java.io.IOException?

Alun Harford

 

[Thomas Weidenfeller]

"BufferedReader foo = new BufferedReader(new InputStream(new
JavaHatesYou(new FuckOffAndDie(new
ForTheLoveOfGodLetMeJustReadTheFile(new
File("filename.txt")))))))));"


I think that speaks for itself.

Java may solve some problems that C and C++ had, but that issue
demonstrated above is just ridiculous

We have comp.lang.java.advocacy. Please use it. fup set.

 

[q_q_anonymous]

Wait a second...
What are you doing with the java.io.IOException?

Alun Harford

yes, that's another thing in java that would make me mad.
Why can't java let you just test if a file exists, if(theFile.exists())
{ read it }

I see that writing the whole try catch exception thing allows for the
case that the file suddenly disappears after i've done the test. But
if that's the case, then let my program crash, and let the user figure
it out. That kind of thing is really outside the realm of what a
programmer can be reasonably expected to test for!
It's not like a programmer should test for a blatant attempt to crash
my program ;-) Or for user negligence.

And the alternative to having the whole try catch exception thing is to
have a throws. But I don't want that propagating up, for reasons stated
above.

 

[Oliver Wong]

I see that writing the whole try catch exception thing allows for the
case that the file suddenly disappears after i've done the test. But
if that's the case, then let my program crash, and let the user figure
it out. That kind of thing is really outside the realm of what a
programmer can be reasonably expected to test for!
It's not like a programmer should test for a blatant attempt to crash
my program ;-) Or for user negligence.

Occasionally, you want your program to NOT crash under any conditions.
Java gives you this possibility. If you want to allow your program to "just
crash" when an FileNotFoundException is thrown, you can do this:

try {
/*Code here which may throw FileNotFoundException*/
} catch (FileNotFoundException e) {
throw new Error("Gave up.", e);
}

And the alternative to having the whole try catch exception thing is to
have a throws. But I don't want that propagating up, for reasons stated
above.

Not nescessarily, as shown above.

- Oliver

 

[Danno]

yes, that's another thing in java that would make me mad.
Why can't java let you just test if a file exists, if(theFile.exists())
{ read it }

http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html#exists()

 

[q_q_anonymous]

http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html#exists()

err, ok, so that tests that the file exists. Part 2 - read the file. I
know it exists, and java wants me to type out a try/catch or throws
with FileNotFoundExceptions looks relatively time consuming and messy.

 

[q_q_anonymous]

Occasionally, you want your program to NOT crash under any conditions.
Java gives you this possibility. If you want to allow your program to "just
crash" when an FileNotFoundException is thrown, you can do this:

yes, I know how to make a program crash from a FileNotFoundException
or how to catch it and throw a different Exception.

My gripe against java, is that I have to write or litter my code with
stuff about FileNotFoundException including Try/Catch or Throws.

try {
/*Code here which may throw FileNotFoundException*/
} catch (FileNotFoundException e) {
throw new Error("Gave up.", e);
}

you are just illustrating my point

Not nescessarily, as shown above.

Look what you showed above. It was a "try catch exception thing "


My point is that I test if a file exists, and that's it, i'm done with
that. I should then be able to read the file, and not write for
FileNotFoundExceptions. It litters the code (relatively) and is
relatively time consuming.


In a mythical pascal/java like language it'd be a bit like

procedure foo
begin
a=assign(abc,'c:\a.txt');
if(abc.exists()==false) {.....[put that right or exit with a
descriptive error]......}

while(i++ <n)
abc.readLn();
end;

and if, ****during that while loop****, the file suddenly vanishes or
becomes unreadable, then let the program crash completely. I don't have
to test for that!!!!!

 

[Roedy Green]

err, ok, so that tests that the file exists. Part 2 - read the file. I
know it exists, and java wants me to type out a try/catch or throws
with FileNotFoundExceptions looks relatively time consuming and messy.

The problem is, in a multiuser system some other job could delete the
file between the time you test and open.

You can just open and catch the exception. You don't need a separate
test.

 

[Patrick May]

Look what you showed above. It was a "try catch exception thing "

My point is that I test if a file exists, and that's it, i'm done
with that. I should then be able to read the file, and not write for
FileNotFoundExceptions. It litters the code (relatively) and is
relatively time consuming.

You have a valid point, but I don't think the ability to turn off
or otherwise completely ignore exceptions is the best solution. In
order to improve the legibility of the code and preserve the
resiliency provided by exception handling, Java needs a proper macro
facility such as that found in Common Lisp. Because of the
increasingly complex syntax of Java, such a facility may be impossible
to develop.

If you're interested in seeing a proper solution to the problem
you have identified, take a look at http://www.gigamonkeys.com/book,
chapters 7 and 8 in particular.

Regards,

Patrick

 

[q_q_anonymous]

You have a valid point, but I don't think the ability to turn off
or otherwise completely ignore exceptions is the best solution. In
order to improve the legibility of the code and preserve the
resiliency provided by exception handling, Java needs a proper macro
facility such as that found in Common Lisp. Because of the
increasingly complex syntax of Java, such a facility may be impossible
to develop.

If you're interested in seeing a proper solution to the problem
you have identified, take a look at http://www.gigamonkeys.com/book,
chapters 7 and 8 in particular.

Regards,

Patrick

Thanks. I'd alway thought that people that criticised exceptions were
bludgeoned to death by the java police.

"It's better than testing for error codes"
"If you had programmed in C or C++, you'd see that Exceptions are much
better than the alternative"
"This whole mandatory exception thing, forcing people to check their
code, is a really good idea"

 

[Oliver Wong]

My point is that I test if a file exists, and that's it, i'm done with
that. I should then be able to read the file, and not write for
FileNotFoundExceptions. It litters the code (relatively) and is
relatively time consuming.


In a mythical pascal/java like language it'd be a bit like

procedure foo
begin
a=assign(abc,'c:\a.txt');
if(abc.exists()==false) {.....[put that right or exit with a
descriptive error]......}

while(i++ <n)
abc.readLn();
end;

and if, ****during that while loop****, the file suddenly vanishes or
becomes unreadable, then let the program crash completely. I don't have
to test for that!!!!!

The point I was getting at is that by having these exceptions, you have
a choice of either doing something with it, or just letting it crash. If
there were no exceptions (i.e. the program just silently fails) then you
would have no choice.

- Oliver

 

[Roedy Green]

Thanks. I'd alway thought that people that criticised exceptions were
bludgeoned to death by the java police.

You get bludgeoned if you troll -- trash something before you
understand it.

 

[EricF]

You have a valid point, but I don't think the ability to turn off
or otherwise completely ignore exceptions is the best solution. In
order to improve the legibility of the code and preserve the
resiliency provided by exception handling, Java needs a proper macro
facility such as that found in Common Lisp. Because of the
increasingly complex syntax of Java, such a facility may be impossible
to develop.

If you're interested in seeing a proper solution to the problem
you have identified, take a look at http://www.gigamonkeys.com/book,
chapters 7 and 8 in particular.

Regards,

Patrick

I missed the original post but I disagree with the point that if the file
exists, you don't need to worry about a FileNotFoundException. Many of us work
in multiuser environments. The file could be deleted right after you check for
its existence. Is this likely? Probably not. But in some environments it could
happen.

I agree that exception handling code can be a pain but turning it off or
ignoring it is not what you want to do. You have the option of letting the
exception propagate to the caller by letting the method throw the exception if
you don't want to deal with it.

It would be great if Java had macro capabilities like Lisp and I will look at
the link. I haven't touched CL since grad school but it was very cool. There
are only 2 things I dislike about Lisp. The parentheses are a pain (I got used
to them) and it's not very marketable.

Eric