Re: a criticism of java

> a)Integer.parseInt was one of the method that got up my nose. It
> throws a NumberFormatException - which is, checked.

The problem with the test-first strategy is that you are duplicating
effort. Nearly all the effort required to parse an int is required to
verify an int.

See the recent thread on "Using exceptions for early exit" in
comp.lang.java.programmer for my suggestions (and some
counter-arguments) on alternative ways of doing this.

> But since i'm writing a single
> user / single thread, application, that sort of mischief isn't
> expected

I would never trust a user (even/especially myself) not to delete a
file under my nose. If you can trust a user, then you are dealing with
a VERY VERY rare case. Most users do mischevious things if they can.

By the way, FileReader is worth avoiding because you can't set its
encoding. It uses the default platform encoding (unless you change
that). It's better to use InputStreamReader, I think.

> Regardign c - br.read(..) . that I can understand, if it's a big
> file, maybe the file will disappear.

I don't think a file can be deleted if you're reading from it, but that
might be OS-dependent. However, a filesystem might disappear,
especially a remote one.

Also, you might close the FileReader before the BufferedReader, so the
BufferedReader has to throw an IOException in that case.

The problem with using this construct:

try
{
code
}
catch (final Exception exception)
{
if (exception instanceof RuntimeException)
throw (RuntimeException(exception;

logger.log(exception);
}

is that it is not explicit. You might think that you're handling an
IOException and a NumberFormatException with it, then you might add
some code that does an SQL query. It will silently start catching
SQLException, and just logging it. It would be better to have to deal
with SQLException, so that you can, e.g., close the database Connection
and System.exit(1); or whatever you want to do in the case of an
SQLException.

Being explicit is good for avoiding bugs, but not good for stopping you
from having to type a lot. I don't mind typing a lot (if you haven't
noticed). I do mind hunting bugs.

.

Relevant Pages

  • Re: SqlException deserialization
    ... InitialCatalog are invalid so a login exception is thrown. ... The stacktrace before serialisation is: ... > without deserialization). ... >> soapformatter and then deserialize and the resulting SqlException has ...
    (microsoft.public.dotnet.framework.adonet)
  • Sqlexception serialization/deserialization
    ... I'm having a problem with a SqlException that I am serializing and ... is a sql exception with the following message: ... StackTrace property. ... soapformatter and then deserialize and the resulting SqlException has ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: wtf?
    ... > called by the ASP classic app, ... >> other than error translation. ... > exception that comes from the command's execute method doesn't seem to ... > the time we might be content saying "SqlException", in this case, we ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: What SqlExceptions can be thrown
    ... There is no case where a SqlException exception would be ... > If all you need to know is if the stored procedure you ran completed ... > have more information based on the specific errors that SQL server returns. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why no "cause" constructors for NumberFormatException
    ... the definition of NumberFormatException? ... based on it) instead of logging and handling it, and why you need a different message if you haven't handled the Exception, and why you have to throw NumberFormatException instead of a custom application-specific Exception since you aren't handling it at first catch, and why you are accepting possibly invalid number formats for conversion instead of prevalidating them in the first place, for all of which we will stipulate that you have good reasons for bucking the best-practices trend. ...
    (comp.lang.java.programmer)