Java is a stupid language

[Darryl L. Pierce]

It could return a nil value.

Which would imply that there *was* a character there and that it was 0.
So you've now gone from "stupid" to "misleading"...

 

[Darryl L. Pierce]

Thus code like this would even work:

if (line.charAt(0) == nil)
else if (line.charAt(0) == 'a')
else if (line.charAt(0) == 'b')
else if (line.charAt(0) == 'c')

Why not do:

if(line.lenght() == 0) {}
else if (line.charAt(0) == 'a') {} // etc...

My suggestion to anybody new to Java or who's an inexperienced
programmer is always: when you think the language designers were
"stupid" for doing something a certain way, first make sure that *YOU*
understand *WHY* they did it that way, because usually you'll find that
the experience language designers know just a wee bit if not more about
how languages ought to work.

 

[Dale King]

Roedy Green wrote:




It could return a nil value.

The nil could be an object, a value, anything you like,
but the point is, provided the function returned somthing
then you always have something to compared.

Thus code like this would even work:

if (line.charAt(0) == nil)
else if (line.charAt(0) == 'a')
else if (line.charAt(0) == 'b')
else if (line.charAt(0) == 'c')

And how about simply doing:

if(line.length() == 0)
else if (line.charAt(0) == 'a')
else if (line.charAt(0) == 'b')
else if (line.charAt(0) == 'c')

 

[jameshanley39]

An example of why Java is a stupid overly complicated
programming language:

import java.io.*;

public class SimpleJavaQuestion
{
public static void main(String[] args)
{
try
{
String line = "";

// surely the first character of the line is not a '#' character
if (line.charAt(0) != '#')
{
System.out.println("Never expect the obvious....");
}
}
catch (Exception e)
{
// stupid me. there is no first character, how obvious!!!!!
System.out.println("When the unexpected is far more interesting.");
}
}
}

AFAIK, you only catch an exception if you can do something useful to
remedy the situation. In this case, tere should be no catch.
Exceptions aren't caught to catch erors in your code. Remove that
catch.

Then, you see there is an error in your code where you neglected to
test if the String was 0 length. line.length()==0 And so the
proram rightly crashes with that Exception.

I have an issue regarding exceptions too.

Say it's Integer.parseInt, the excuse there for an Exception, is
'what integer do you expect it to return". So you gotta put in the
whole crazy Exception handling code. So here's a better example

from memory-
When you use FileReader and pass it a File. The FileReader constructor
has an exception like a FileNotFoundException. It has to be caught or
declared. What a nuisance. Why can't there be a function to test if the
file exists. Meaning, that if it doesn't exist, and I try to open it,
then the error is in my code. One possible answer, is that the file
may all of a sudden disapear, I cannot test for that, thus a try Catch
is necessary. Perhaps many exceptions are necessary for things that can
happen any time and thus need to be continuously tested for, and don't
necessarily indicate an error in your code.
I personally think that you should tset if the file exists before
opening the file. and if somewhere somehow you read the file and it
doesn't exist (like the file disappears from memory, or tere as an
error in the code) Then the FileNotFoundException should be thrown. let
the program Exit if you don't want to deal with that possibility of the
file vanshing from the HDD or memory during processing!!!. You can't
write code for every possibility imaginable. To me, exceptions like
this seem fanciful.

The NullPointerException, I see no reason to catch. If it occurs, it's
an error on your code.

 

[Raymond Martineau]

An example of why Java is a stupid overly complicated
programming language:

[...]

AFAIK, you only catch an exception if you can do something useful to
remedy the situation. In this case, tere should be no catch.
Exceptions aren't caught to catch erors in your code. Remove that
catch.

Even if it is necessairy to catch the exception, it should be as mimimal to
catch only thrown exceptions. (e.g. NullPointerException.)

The NullPointerException, I see no reason to catch. If it occurs, it's
an error on your code.

Actually, catching RuntimeException will prevent the Java app from dropping
completely when the program terminates. While you are supposed to fix
those problems, one or two could potentially slip through.

It's usually best to wrap those catches around optional components or third
party plugins. Other than that (and RTEs that can be generated through
user input), there's not much use for doing so.

 

[Jussi Piitulainen]

Actually, catching RuntimeException will prevent the Java app from
dropping completely when the program terminates. While you are
supposed to fix those problems, one or two could potentially slip
through.

I've written several programs this way:

public static void main(String [] args) {
try {
submain(args);
}
catch (Throwable exn) {
write trace to stderr and to a log file (with care)
exit
}
}

This way I can deal with all unexpected exceptions in this one place.
There is nothing to be done other than make sure that I do not lose
that trace.

 

[Raymond DeCampo]

An example of why Java is a stupid overly complicated
programming language:

[...]

AFAIK, you only catch an exception if you can do something useful to
remedy the situation. In this case, tere should be no catch.
Exceptions aren't caught to catch erors in your code. Remove that
catch.

Even if it is necessairy to catch the exception, it should be as mimimal to
catch only thrown exceptions. (e.g. NullPointerException.)

The NullPointerException, I see no reason to catch. If it occurs, it's
an error on your code.

Actually, catching RuntimeException will prevent the Java app from dropping
completely when the program terminates. While you are supposed to fix
those problems, one or two could potentially slip through.

It's usually best to wrap those catches around optional components or third
party plugins. Other than that (and RTEs that can be generated through
user input), there's not much use for doing so.

Another scenario is a production application that you want to be more
user friendly than simply crashing when there is a bug.

Ray

 

[Babu Kalakrishnan]

I've written several programs this way:

public static void main(String [] args) {
try {
submain(args);
}
catch (Throwable exn) {
write trace to stderr and to a log file (with care)
exit
}
}

This way I can deal with all unexpected exceptions in this one place.
There is nothing to be done other than make sure that I do not lose
that trace.

And I presume all those applications were single-threaded ? Most Java
apps don't fall in that category - unfortunately.

BK

 

[Jussi Piitulainen]

I've written several programs this way:
public static void main(String [] args) {
try {
submain(args);
}
catch (Throwable exn) {
write trace to stderr and to a log file (with care)
exit
}
}
This way I can deal with all unexpected exceptions in this one place.
There is nothing to be done other than make sure that I do not lose
that trace.

And I presume all those applications were single-threaded ? Most
Java apps don't fall in that category - unfortunately.

Yes, they are all single-threaded. Batch computation, not interactive.

Years ago I tried to set one AWT-using program up this way, and there
was some way to catch exceptions from AWT. I never found out how
official or how portable it was, but sometimes at least it worked.

 

[Babu Kalakrishnan]

Babu Kalakrishnan writes:

I've written several programs this way:
public static void main(String [] args) {
try {
submain(args);
}
catch (Throwable exn) {
write trace to stderr and to a log file (with care)
exit
}
}
This way I can deal with all unexpected exceptions in this one place.
There is nothing to be done other than make sure that I do not lose
that trace.

And I presume all those applications were single-threaded ? Most
Java apps don't fall in that category - unfortunately.

Yes, they are all single-threaded. Batch computation, not interactive.

Years ago I tried to set one AWT-using program up this way, and there
was some way to catch exceptions from AWT. I never found out how
official or how portable it was, but sometimes at least it worked.

Yes te AWT thread does handle its exceptions in such a way that it
doesnt allow the thread to terminate because of an Exception (except for
may be fatal ones such as an OutOfMemoryError or a StackOverFlow).
Otherwise it simply prints out a stacktrace to stderr and continues on
its way.

BK