Re: a criticism of java


Hendrik Maryns wrote:
> I think it all boils down to a different point of view, and neither of
> us will convince the other, so you may read the rest of my reply, or
> just ignore it. Sorry for the top-post.

The throws clause is part of the language and not an effective tool for
documenting the method. If you use it as such, then you have to deal
with the fact that it doesn't demand listing 'unchecked exceptions'*,
and doesn't list preconditions and postconditions.
Documentation should be in English rather than java code that wasn't
intended for that!

(* I personally wouldn't document all kinds of unchecked exceptions.
Cerainly not programmer errors. Maybe some related to outside
environment though. )


Not having checked exceptions declared in those instances as I
suggested, will not make the program less robust. If they are
declared, as you would. Or if they are not declared as I would, it
still means that we're not dealing with it.

In the rare event that the user will deal with an unchecked exception
(and they are rare hence the exception is unchecked).
In that rare event, the user may catch the exception, he has the
choice to do so, but he is not forced to catch or declare it. To
force the programmer to do so, is a self imposed restriction that comes
at too great a cost. It's absurd to list all the unchecked exceptions
in the throws clause, as you suggest. Especially programmer errors
within the method, like NullPointerException. Do you think the user of
the method is going to see that and think "arr, I forgot that might be
throw, I might want to catch it". The user of the method should be
aware that exception may be thrown. Checked exceptions come at a great
cost.

A programmer that isn't absolutely aweful, can write robust code with
just unchecked exceptions. He doesn't have to be forced to catch one
or to declare every unforeseen possibility in java code. possibilities
which will rarely be dealt with, but can be dealt with even without him
listing them in java code. His only excuse is he is abusing it as a
documentation tool, that is crazy. It's java code!


How about writing good code, and good documentation ! And not try to
include documentation in a throws clause, cluttering the method header,
cluttering the method body. And, as I said. Documentation shouldn't be
in java code. so, i'm not saying it shouldn't be in non english.
Efforts are being made in academic circles to use mathematical symbols
to document programs. e.g. to say that an array is sorted.
But the point is that java code isn't flexible enough to do this. It
wasn't built for documenting programs.

I am all for descriptive documentation, and that does take longer to
write.

I also put an IAE in the throws clause. Because I manually throw an IAE
with a descriptive String. It's not an unchecked exception that just
gets thrown due to my error or the outside environment. It's user
error, and I want him to know he can't get away with it! But this is no
replacement for proper documentation. I would never let my throws
clause document my program at the cost of my code Or at the cost of
causing unnecessary frustration to the user of the method!!








> q_q_anonymous@xxxxxxxxxxx schreef:
> > Hendrik Maryns wrote:
> >
> >>q_q_anonymous@xxxxxxxxxxx schreef:
> >>
> >>>Hendrik Maryns wrote:
> >>>
> >>>
> >>>>q_q_anonymous@xxxxxxxxxxx schreef:
> >>>><a lot>
> >>>>
> >>>>>I would still throw an IllegalArgumentException with every method, -
> >>>>>not intended to be caught. Including a String describing the mistake.
> >>>>>For somebody to call a method without testing the arguments they pass
> >>>>>to it, relying on the method they call to test whether their arguments
> >>>>>are valid, then getting an IllegalArgumentException from the method
> >>>>>telling them what argumetn was invalid, and them catching it, and
> >>>>>writing error recovery code, is ridiculous. If they can put error
> >>>>>recovery code in a catch - which is rather late - then they can put it
> >>>>>early before they call the method!
> >>>>
> >>>>I suppose you aren´t a fan of design on contract either?
> >>>>
> >>>
> >>>
> >>>You mean strictly defining what goes in and out of the method - so the
> >>>method is designed to fulfill a contract with its user ? Of course I
> >>>believe in that.
> >>>
> >>>I would test the arguments very carefully and throw
> >>>IllegalArgumentExceptions if they screw up. I consider them calling my
> >>>method with illegal arguments to be them screwing up - programmer
> >>>error.
> >>>
> >>>I'm not sure what text I wrote could have possibly led you to believe
> >>>what you wrote.
> >>
> >>Well then you should know that the method signature is a part of the
> >>contract,
> >
> >
> > not the way I am using it. The throws Exception isn't saying this
> > method WILL throw anything.
>
> Indeed, it only warns that the method /could/ throw that particular
> exception. And if you take DBC seriously, you will mention in the docs
> under what circumstances that is possible. Thus, the example you gave
> in another post:
>
> public void methodX() throws Exception
> {
> ....
> if (isInt(string))
> int x = parseInt(string);
> else
> System.out.println("Not an Int");
> }
>
> is rather ridiculous, as now you have to bother the client of the method
> with reading that you do declare an exception can be thrown, but then
> you document that actually, it can´t. Why not just put a try/catch
> around it and not bother the client of your method?
>
> It doesn't actually change what the method
> > throws. It does mean that the code within the method reads a lot
> > better.
>
> I think the code within a method is much less important than that what
> the client gets to see, i.e. the method signature and the documentation.
>
> > in a single user system, a FileNotFoundException while i'm reading a
> > small file is very exceptional. And I won't be dealing with it. Just
> > like I won't be dealing with an Out Of Memory Exception. As far as
> > I'm concerned, it should be unchecked.
>
> Ok, but a single user system is not what Java was built for, and for
> much applications is not the rule, but the exception.
>
> Funny thing is, there are others that claim UNchecked exceptions are a
> misdesign... (and I tend to agree with them, I always document when a
> method might throw an NPE or IAE or ...)
>
> > So the throws Exception is a workaround for the problem that i'd like
> <snip>
> Indeed, good for a one-person program, which once again is not the rule
> but the exception.
>
> > If the user really wants to, he can recover from it. But I am the main
> > user of the method, and I can comment that the FileNotFoundException
> > isn't thrown, and I am writing the method for users that don't
> > typically want to recover from it.
>
> And you are sure you will never have to hand over your code to another
> maintainer?
>
> > If they want to it's no problem, they can write their own catch.
> > Just like they can for any other unchecked Exception ilke out of
> > memory exception, or any exception that is outside the programmer's
> > control.
>
> >>so adding unnecessary throws declarations is just making the
> >>contract less attractable.
> >
> > The way i'm using the throws, it shouldn't be read as part of the
> > contract.
>
> But unfortunately, it is.
>
> It makes no difference to the existing contract. It says
> > nothing extra. It just says this method could throw an Exception.
> > It makes the code inside the method a lot neater, and the code is just
> > as strong. THe purpose of the throws clause is not for the contract -
> > the way I use it , it says nothing.
>
> But how is your client supposed to know that? Probably because you
> document it, but then that is just as much work, no?
>
> >>You talk about documenting when which errors
> >>can be thrown, why not do part of that in the method signature?
> > For the same reason that certain exceptions were made Unchecked. The
> > same reason that sun made sure you don't have to write Out of memroy
> > exception in the throws clause.or null pointer exception. These are
> > errors - I think - that are either outside of the programmer's control
> > and thep rogrammer may just want to have the program crash-exit or
> > they are programmer errors.
>
> You have a point, and there would be no need for many of those
> exceptions if there was a precondition system that checked for null
> values and the like. (Maybe I really should switch to Eiffel)
>
> > I am treating the NumberFormatException thrown by parseInt as an
> > IllegalArgumentException, and therefore, something which sun recognizes
> > is an unchecked exception and wouldn't be declared, because if it were
> > thrown, it'd be programmer error. You don't write code to recover from
> > them. You crash-exit
>
> Depending on how robust you want your program, even if it is an
> auxiliary class. Robustness vs. efficiency, the usual dilemma, right?
>
>
> --
> Hendrik Maryns
>
> ==================
> www.lieverleven.be
> http://aouw.org

.

Relevant Pages

  • Re: jambands.com letter to the editor
    ... >>> copying, period, without permission. ... with the exception of brief excerpts in critical ... > have made a statement here that is contrary to the documentation that I have ... prohibited from making photocopies, such as the "documentation" you have ...
    (rec.music.gdead)
  • Re: Source code documentation
    ... An error occured while trying to build the documentation. ... Exception: NDoc.Core.DocumenterException ... Please verify that the HTML Help Workshop has been installed. ... bei NDoc.Documenter.Msdn.MsdnDocumenter.Buildin C:\Dokumente und ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Problems Handling Errors Correctly
    ... remember the web site off hand but Google "SandCastle help generator" and you'll find a utility that turns the xml file generated from the code comments into MSDN style documentation ... Every once in a while you'll get an exception that's thrown from deep in the stack that doesn't seem intuitve, but for me it's usually when I'm dealing with remoting or xml stuff. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How do I get the equivalent status (DEC ADA IMPORT_EXCEPTION)
    ... But you asked about examining subordinate chained messages, ... The documentation describes the Condition ... >> And then use the imported exception values for the documented codes ... > rather cumbersome mapping of exceptions back to status ...
    (comp.os.vms)
  • Re: Why are Boost thread mutexes so slow compared to Pthreads?
    ... be bound with a lock. ... MT programmer should have problems understanding. ... as that element MUST have a different locking scheme. ... This is the "strong guarantee" in exception safe coding, ...
    (comp.programming.threads)