Exception questions

[Rhino]

I'm afraid I have some confusion about checked and unchecked exceptions.

First, am I correct in believing that a checked exception is one in which
the method signature contains the throws clause? For example:

public void myMethod(int foo) throws SuchAndSuchException { }

In other words, is the sole definition of whether an exception is checked
or unchecked consist of whether it is in a throws clause in the method
signature? Or is there more to recognizing the existence of a checked
exception in existing code?

Second, the Java Tutorial has a topic on the inappropriate use of unchecked
exceptions -
http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html -
and basically advocates that if a given situation might be recoverable for
the calling application, a checked exception should be thrown, not an
unchecked one.

I'm revisiting some old classes that I wrote to try to make them as good as
I can and many of the methods in it detect bad input to the methods and
throw IllegalArgumentException. For example, one method examines a String
representation of a year to see if that year is a leap year and throws
IllegalArgumentException if the year portion of the date is "0000" since
there never was a Year Zero. (The year 1 BC was followed immediately by 1
AD).

However, I don't currently have a throws clause in the method signature and
I'm thinking I probably should. Have I got that right?

 

[Jean-Baptiste Nizet]

I'm afraid I have some confusion about checked and unchecked exceptions.

First, am I correct in believing that a checked exception is one in which
the method signature contains the throws clause? For example:

  public void myMethod(int foo) throws SuchAndSuchException { }

In other words, is the sole definition of whether an exception is checked
or unchecked consist of whether it is in a throws clause in the method
signature? Or is there more to recognizing the existence of a checked
exception in existing code?

No, you aren't right. Runtime exceptions are exceptions which have
RuntimeException as one of their ancestor classes (i.e. which extend
RuntimeException or one of its subclasses, or one of its
subsubclasses, etc.)
Checked exceptions are all the other ones.

Second, the Java Tutorial has a topic on the inappropriate use of unchecked
exceptions -http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime....-
and basically advocates that if a given situation might be recoverable for
the calling application, a checked exception should be thrown, not an
unchecked one.

I'm revisiting some old classes that I wrote to try to make them as good as
I can and many of the methods in it detect bad input to the methods and
throw IllegalArgumentException. For example, one method examines a String
representation of a year to see if that year is a leap year and throws
IllegalArgumentException if the year portion of the date is "0000" since
there never was a Year Zero. (The year 1 BC was followed immediately by 1
AD).

However, I don't currently have a throws clause in the method signature and
I'm thinking I probably should. Have I got that right?

You may or may not add the runtime exceptions your method might throw
in the throws clause. Usually, they're included in the throws clause
in order to be documented by javadoc.

Runtime exceptions should be used to signal unrecoverable problems
(example : the database is down), or to signal programmer errors.
For example, if your method documentation (its contract) says that a
given argument must be a string with at least 3 chars, you should use
an IllegalArgumentException when it's not the case. If the class
documentation (its contract) says that the init method must be called
before any other one, you should use an IllegalStateException if it's
not the case.
But if the job of a method is to parse user-entered value in order to
validate it has a given format, it should throw a checked exception if
it's not the case, since the caller of your method can't make sure the
string is in the valid format before calluing it (it's the method's
job in the first place).

JB.

 

[Roedy Green]

In other words, is the sole definition of whether an exception is checked
or unchecked consist of whether it is in a throws clause in the method
signature? Or is there more to recognizing the existence of a checked
exception in existing code?

see http://mindprod.com/jgloss/exception.html#TYPES
--
Roedy Green Canadian Mind Products
http://mindprod.com

Responsible Development is the style of development I aspire to now. It can be summarized by answering the question, “How would I develop if it were my money?” I’m amazed how many theoretical arguments evaporate when faced with this question.
~ Kent Beck (born: 1961 age: 49) , evangelist for extreme programming.

 

[Mike Schilling]

I'm afraid I have some confusion about checked and unchecked
exceptions.

First, am I correct in believing that a checked exception is one in
which the method signature contains the throws clause? For example:

public void myMethod(int foo) throws SuchAndSuchException { }

In other words, is the sole definition of whether an exception is
checked or unchecked consist of whether it is in a throws clause in
the method signature? Or is there more to recognizing the existence
of a checked exception in existing code?

A checked exception is a class which is a subtype of Exception but is not a
subtype of RuntimeException. If a method throws a checked exception, it
must list the execeptions's class (or a supertype thereof) in its throws
clause. It's OK to mention unchecked excpetions in the throws clause, as a
form of documentation, but it's not required.

 

[Lew]

No, you aren't right. Runtime exceptions are exceptions which have
RuntimeException as one of their ancestor classes (i.e. which extend
RuntimeException or one of its subclasses, or one of its
subsubclasses, etc.)
Checked exceptions are all the other ones.

.... that extend 'Exception'.

That's not exactly true, and is controversial.

My rule of thumb is that unchecked exceptions are for programmer
mistakes, like 'IllegalArgumentException', and checked exceptions are
for environmental situations, like 'IOException'. People also use
unchecked exceptions when they don't want to force client calling code
to deal with them.

Checked exceptions force calling code to catch them, that's their
advantage.

No.

You may or may not add the runtime exceptions your method might throw
in the throws clause. Usually, they're included in the throws clause
in order to be documented by javadoc.

You don't need to put unchecked exceptions in the method signature in

Runtime exceptions should be used to signal unrecoverable problems
(example : the database is down), or to signal programmer errors.
For example, if your method documentation (its contract) says that a
given argument must be a string with at least 3 chars, you should use
an IllegalArgumentException when it's not the case. If the class
documentation (its contract) says that the init method must be called
before any other one, you should use an IllegalStateException if it's
not the case.
But if the job of a method is to parse user-entered value in order to
validate it has a given format, it should throw a checked exception if
it's not the case, since the caller of your method can't make sure the
string is in the valid format before calluing it (it's the method's
job in the first place).

"Recoverable" is such a loose term. Most unchecked exceptions are
recoverable, e.g., if you get 'NullPointerException' you just return
'null' or call the method again with a default argument, so it's a
very useless rule of thumb to say "use runtime or checked for
[un]recoverable exceptions".

How do you recover from a missing file that is necessary for your
program? That's signaled by a checked exception ('IOException'), but
might not fit your definition of "recoverable". OTOH, it is almost
certainly environmental, not a programmer error, so a checked
exception makes sense.

Programmers of methods that call methods with checked exceptions often
pule about what a "bother" it is to have to catch them. Pooh widdoo
widdoo cwybabies, awwww. API writers (i.e., the methods' authors) put
checked exceptions in there on purpose, to force calling code to catch
them and (presumably) to recover from them. If the API writer deems
such autocracy unnecessary, they'll toss an unchecked exception and
just let the caller explode without forewarning.

So maybe the rule of thumb is, "If the caller should have prevented
the exception and you don't want to be bothered with warning them
because they should have known better, throw an unchecked exception.
If the caller cannot reasonably be expected to prevent the exception
by their own diligence, throw a checked exception." It's really up to
the API writer to choose.

 

[Lew]

It's OK to mention unchecked excpetions in the throws clause, as a
form of documentation, but it's not required.

It's not helpful, either, so don't do that.

Pretty useless form of documentation, requiring the caller's author to
read the source of the invoked method in order to know about the
unchecked exception. Nor does including an unchecked exception in the
signature force the caller to catch it. So really, don't bother doing
that. Useless is harmful.

If you want to document unchecked exceptions usefully, do so in the
Javadocs. I recommend a combination of '@throws' clauses and verbiage
in the method explanation.

 

[Rhino]

No, you aren't right. Runtime exceptions are exceptions which have
RuntimeException as one of their ancestor classes (i.e. which extend
RuntimeException or one of its subclasses, or one of its
subsubclasses, etc.)
Checked exceptions are all the other ones.

... that extend 'Exception'.

That's not exactly true, and is controversial.

My rule of thumb is that unchecked exceptions are for programmer
mistakes, like 'IllegalArgumentException', and checked exceptions are
for environmental situations, like 'IOException'. People also use
unchecked exceptions when they don't want to force client calling code
to deal with them.

Checked exceptions force calling code to catch them, that's their
advantage.

No.

You may or may not add the runtime exceptions your method might throw
in the throws clause. Usually, they're included in the throws clause
in order to be documented by javadoc.

You don't need to put unchecked exceptions in the method signature in

Runtime exceptions should be used to signal unrecoverable problems
(example : the database is down), or to signal programmer errors.
For example, if your method documentation (its contract) says that a
given argument must be a string with at least 3 chars, you should use
an IllegalArgumentException when it's not the case. If the class
documentation (its contract) says that the init method must be called
before any other one, you should use an IllegalStateException if it's
not the case.
But if the job of a method is to parse user-entered value in order to
validate it has a given format, it should throw a checked exception
if it's not the case, since the caller of your method can't make sure
the string is in the valid format before calluing it (it's the
method's job in the first place).

"Recoverable" is such a loose term. Most unchecked exceptions are
recoverable, e.g., if you get 'NullPointerException' you just return
'null' or call the method again with a default argument, so it's a
very useless rule of thumb to say "use runtime or checked for
[un]recoverable exceptions".

How do you recover from a missing file that is necessary for your
program? That's signaled by a checked exception ('IOException'), but
might not fit your definition of "recoverable". OTOH, it is almost
certainly environmental, not a programmer error, so a checked
exception makes sense.

Programmers of methods that call methods with checked exceptions often
pule about what a "bother" it is to have to catch them. Pooh widdoo
widdoo cwybabies, awwww. API writers (i.e., the methods' authors) put
checked exceptions in there on purpose, to force calling code to catch
them and (presumably) to recover from them. If the API writer deems
such autocracy unnecessary, they'll toss an unchecked exception and
just let the caller explode without forewarning.

So maybe the rule of thumb is, "If the caller should have prevented
the exception and you don't want to be bothered with warning them
because they should have known better, throw an unchecked exception.
If the caller cannot reasonably be expected to prevent the exception
by their own diligence, throw a checked exception." It's really up to
the API writer to choose.

So, trying to put this all together, would you agree with this reasoning?

1. In the example I've cited, where the method is going to determine if a
year expressed as a String is a leap year, it is appropriate to throw an
exception (IllegalArgumentException which is a subclass of
RuntimeException) if the year is zero.
2. This situation is recoverable since the user could easily correct this
if it was brought to his attention.
3. IllegalArgumentException should be put in the throws clause of the
message signature.
4. The Javadoc @throws (or @exception) should list
IllegalArgumentException.
5. IllegalArgumentException is RuntimeException since RuntimeException is
its ancestor but IllegalArgumentException is NOT a checked exception
because checked exceptions are never instances of RuntimeException or one
of its descendents.

 

[Lew]

(Please trim your posts.)

So, trying to put this all together, would you agree with this reasoning?

1. In the example I've cited, where the method is going to determine if a
year expressed as a String is a leap year, it is appropriate to throw an
exception (IllegalArgumentException which is a subclass of
RuntimeException) if the year is zero.

Why do you want to do that? What's special about year zero?

If the Javadocs indicate that year "0" should never be an argument to
the method, then 'IllegalArgumentException' is a good approach, but
otherwise it's not.

Just out of curiosity:
- Why not just use 'GregorianCalendar#isLeapYear(int year)'? FWIW,
that method takes 0 as a legitimate argument, signifying BC 1.

- Are you going to reject dates prior to 1582 in the Catholic world,
1700 in Scandinavia, 1753 in Sweden or 1752 in the former British
Empire?

- Are you aware that New Year's Day was on March 25 prior to the
adoption of the Gregorian calendar? (You would be if you read
Javadocs.)

2. This situation is recoverable since the user could easily correct this
if it was brought to his attention.

And therefore ...?

I don't see what being "recoverable" has to do with anything. What
exactly do you mean by "recoverable" anyway?

3. IllegalArgumentException should be put in the throws clause of the
message signature.

No. Bad idea.

4. The Javadoc @throws (or @exception) should list
IllegalArgumentException.

If you want that documented, yes. At the very least you'd want that
information in the body of the Javadoc for the method.

However, I don't think I'd consider "0" an illegal argument if it were
I writing the method, which I wouldn't because I'd use
'GregorianCalendar' and not reinvent the wheel.

5. IllegalArgumentException is RuntimeException since RuntimeException is
its ancestor but IllegalArgumentException is NOT a checked exception
because checked exceptions are never instances of RuntimeException or one
of its descendents [sic].

True by definition.

It's a bad idea to put unchecked exceptions in the 'throws' clause of
a method signature.

 

[Rhino]

(Please trim your posts.)

Actually, I would but in other threads people have said they're leaving
theirs intact for the benefit of those using Google groups. Won't I be
preventing Google Groups users from benefitting from this discussion if I
trim my posts?

Why do you want to do that? What's special about year zero?

As I mentioned in the original post, the year 0 never happened - the
calendar went straight from the year 1 BC to 1 AD. Therefore, if someone
put "0" (or "00" or "000" or "0000") in a form that asked for a year,
they'd be inputting an invalid year.

If the Javadocs indicate that year "0" should never be an argument to
the method, then 'IllegalArgumentException' is a good approach, but
otherwise it's not.

Just out of curiosity:
- Why not just use 'GregorianCalendar#isLeapYear(int year)'? FWIW,
that method takes 0 as a legitimate argument, signifying BC 1.

Huh? Interpreting 0 as BC 1 makes no sense to me.

- Are you going to reject dates prior to 1582 in the Catholic world,
1700 in Scandinavia, 1753 in Sweden or 1752 in the former British
Empire?

Who said anything about rejecting those dates?

- Are you aware that New Year's Day was on March 25 prior to the
adoption of the Gregorian calendar? (You would be if you read
Javadocs.)

Yes, actually I did know that. And I have read Javadocs.

And therefore ...?

I'm just trying to lay out my reasoning on the basis of what you and
others have said on this subject to make sure I'm thinking this through
correctly.

I don't see what being "recoverable" has to do with anything. What
exactly do you mean by "recoverable" anyway?

One of the criteria for whether to make something a checked or unchecked
exception is whether an error is "recoverable", meaning (loosely) that
there is some prospect that the error can be eliminated with a bit of
human intervention. In this case, that human intervention would be
displaying a message to the user saying that the year 0000 is not valid
and please change it to a year that actually existed.

No. Bad idea.

Why?

If you want that documented, yes. At the very least you'd want that
information in the body of the Javadoc for the method.

However, I don't think I'd consider "0" an illegal argument if it were
I writing the method, which I wouldn't because I'd use
'GregorianCalendar' and not reinvent the wheel.

If GregorianCalendar is going to interpret the year 0 as the 1 BC without
my telling it to, I'm not sure I want to use GregorianCalendar....

5. IllegalArgumentException is RuntimeException since
RuntimeException is its ancestor but IllegalArgumentException is NOT
a checked exception because checked exceptions are never instances of
RuntimeException or one of its descendents [sic].

True by definition.

It's a bad idea to put unchecked exceptions in the 'throws' clause of
a method signature.

Anyway, the year 0 is not really important here. I'm just trying to
construct an example of what I consider a "recoverable" (for want of a
better word) error so that I can see if I am understanding the use of
checked and unchecked exceptions yet.

 

[Lew]

Lew wrote

Actually, I would but in other threads people have said they're leaving
theirs intact for the benefit of those using Google groups. Won't I be
preventing Google Groups users from benefitting from this discussion if I
trim my posts?

No, quite the contrary. And so what if you did?

As I mentioned in the original post, the year 0 never happened - the
calendar went straight from the year 1 BC to 1 AD. Therefore, if someone
put "0" (or "00" or "000" or "0000") in a form that asked for a year,
they'd be inputting an invalid year.  

The year 1 never happened either. Neither did the year 100. Are you
going to reject those years, too?

Note, again, that the standard Java API does accept the year 0,
because it uses the proleptic Gregorian calendar.

Are you going to reject October 10, 1582? That only happened some
places. Are you going to consider February 28, 1560, to be in the
same year as October 28, 1560? That would be wrong. Do you consider
that Cervantes and Shakespeare died on the same day because they died

Huh? Interpreting 0 as BC 1 makes no sense to me.

That's because you haven't studied calendars very much, and apparently
haven't bothered to read the Javadocs very much either.

Who said anything about rejecting those dates?

Well, they didn't happen in the Gregorian calendar. Why wouldn't you
reject them?

And am I not permitted to introduce a new concept, or must everything
I suggest have been brought up already before I comment?

Yes, actually I did know that. And I have read Javadocs.  

Then you already knew about the proleptic Gregorian calendar and that
the Java 'GregorianCalendar' accepts year 0.

I'm just trying to lay out my reasoning on the basis of what you and
others have said on this subject to make sure I'm thinking this through
correctly.

Well, I pointed out that "recoverable" was not relevant, as it is far
too loose a concept that can apply to both checked and unchecked
exceptions, and therefore does not distinguish when to use one or the
other.

One of the criteria for whether to make something a checked or unchecked
exception is whether an error is "recoverable", meaning (loosely) that

No, it isn't.

there is some prospect that the error can be eliminated with a bit of
human intervention. In this case, that human intervention would be
displaying a message to the user saying that the year 0000 is not valid
and please change it to a year that actually existed.

That reasoning applies equally well to checked or unchecked
exceptions.

Why?

As I have said a couple of times already in this thread, and surely
you have read, because it accomplishes nothing. It does not add to
the documentation, it does not become part of the method signature, it
does not require callers to catch the exception, and it's a waste of
time and effort. The 'throws' clause is designed for and only useful
with checked exceptions.

If GregorianCalendar is going to interpret the year 0 as the 1 BC without
my telling it to, I'm not sure I want to use GregorianCalendar....

But that is correct behavior, by ISO standard 8601. You really need
to study up on calendars, particularly the Gregorian calendar. May I
suggest careful study of
<http://en.wikipedia.org/wiki/Gregorian_calendar>
particularly
<http://en.wikipedia.org/wiki/
Gregorian_calendar#Proleptic_Gregorian_calendar>
?

Sometimes people, and APIs, do the right thing even if you don't tell
them to. Furthermore, it is not your job to tell the standard API
what to do, but the standard API's job to tell you what it actually
does. As long as it works as documented, then you have no legitimate
gripe.

Anyway, the year 0 is not really important here. I'm just trying to
construct an example of what I consider a "recoverable" (for want of a
better word) error so that I can see if I am understanding the use of
checked and unchecked exceptions yet.

"Recoverable" is an awful, terrible, vague, useless, unworthy and
ridiculous criterion for choosing between the two. Instead, consider
either
- RuntimeException for programmer error, checked exception for
environmental error, or
- RuntimeException to let a caller slide without a 'catch' clause,
checked exception to force the 'catch'.

Whatever criterion you use, it's going to be a matter of style. There
are entire APIs out there that refuse to throw checked exceptions by
dint of the API writers' philosophy, others that go hog-wild with
them. It's up to the API writer what they choose to impose.

 

[Rhino]

Lew wrote


No, quite the contrary. And so what if you did?

Surely one of the benefits of newsgroups is that they allow other people
to look at archived questions and learn from them. If the archived
materials are severely trimmed, that could make it much harder to learn
from.

The year 1 never happened either. Neither did the year 100. Are you
going to reject those years, too?

Again, I don't particularly want to dwell on the year 0 here. I
introduced this merely as an example of something that might be a
candidate for a checked exception.

I don't claim to be a guru on the history of time but I am interested in
history, although mostly contemporary history rather than the Roman era.
If the year 0 did exist and the years 1 and 100 didn't, this is the first
I'm hearing of it. No history course I ever took at high school or
university suggested any such thing. The teachers I had talked about B.C.
and A.D. and said that 1 A.D followed 1 B.C. and that there was no year
0. Umpteen timelines all followed that same model.

[Now, I recognize that a lot of this is "retroactive" in the sense that
the Romans didn't start distinguishing between B.C and A.D in the year I
would call 1 A.D. Western historians started doing that well after the
fact. Perhaps that's what you mean when you say the year 0 did exist and
the years 1 and 100 did not??]

Note, again, that the standard Java API does accept the year 0,
because it uses the proleptic Gregorian calendar.

Are you going to reject October 10, 1582? That only happened some
places. Are you going to consider February 28, 1560, to be in the
same year as October 28, 1560? That would be wrong. Do you consider
that Cervantes and Shakespeare died on the same day because they died



That's because you haven't studied calendars very much, and apparently
haven't bothered to read the Javadocs very much either.

For pity sake, I DID read the Javadocs, although I didn't necessarily
understand everything I saw. I am now going to assume that I've said that
enough times that I don't need to say it again.

Well, they didn't happen in the Gregorian calendar. Why wouldn't you
reject them?

I am not clear on what a Gregorian calendar does with dates before the
establishment of the Gregorian calendar in 1582 (for the Catholic
countries and later for other countries.)

I am not trying to become an expert in the history of timekeeping. I'm
trying to ask a question about checked and unchecked exceptions. The
example that I thought would represent a simple illustration of a
validation in a method has obviously backfired on me. So let me just
contruct a new example that will, I hope, be less controversial so that I
can actually confirm my understanding of exceptions.

And am I not permitted to introduce a new concept, or must everything
I suggest have been brought up already before I comment?

I said nothing of the kind. I don't know where you are getting that.

Then you already knew about the proleptic Gregorian calendar and that
the Java 'GregorianCalendar' accepts year 0.



Well, I pointed out that "recoverable" was not relevant, as it is far
too loose a concept that can apply to both checked and unchecked
exceptions, and therefore does not distinguish when to use one or the
other.

And that's why I tried to put the concept in somewhat more practical
terms.

No, it isn't.


That reasoning applies equally well to checked or unchecked
exceptions.

Then I am still not clear on when I would use a checked exception and
when I would not.

I do NOT want to open this Year 0 can of worms again so let's try
something that will hopefully be less controversial.

I have a method called getSeconds. Its job is simply to take a number of
hours, minutes and seconds and convert that to seconds. Here is the code,
minus the comments (for brevity):

public int getSeconds(int hours, int minutes, int seconds) {

if (hours < 0) {
Object[] msgArgs = {new Integer(hours)};
msgFmt.applyPattern(locMsg.getString("msg032"));
throw new IllegalArgumentException(msgFmt.format(msgArgs));
}

if (minutes < 0) {
Object[] msgArgs = {new Integer(minutes)};
msgFmt.applyPattern(locMsg.getString("msg033"));
throw new IllegalArgumentException(msgFmt.format(msgArgs));
}

if (seconds < 0) {
Object[] msgArgs = {new Integer(seconds)};
msgFmt.applyPattern(locMsg.getString("msg034"));
throw new IllegalArgumentException(msgFmt.format(msgArgs));
}

return (hours * HoursMinutesSeconds.SECONDS_IN_ONE_HOUR)
+ (minutes * HoursMinutesSeconds.SECONDS_IN_ONE_MINUTE)
+ seconds;
}

Can we agree that it makes no sense to have negative hours, minutes and
seconds and that if the calling program supplies negative numbers for any
of those parameters, it is reasonable to notify the caller of this fact
so that the caller can, perhaps, remedy the situation?

Would we agree that this example illustrates a proper use of unchecked
exceptions?

As I have said a couple of times already in this thread, and surely
you have read, because it accomplishes nothing. It does not add to
the documentation, it does not become part of the method signature, it
does not require callers to catch the exception, and it's a waste of
time and effort. The 'throws' clause is designed for and only useful
with checked exceptions.

Okay, fine.

But that is correct behavior, by ISO standard 8601. You really need
to study up on calendars, particularly the Gregorian calendar. May I
suggest careful study of
<http://en.wikipedia.org/wiki/Gregorian_calendar>
particularly
<http://en.wikipedia.org/wiki/
Gregorian_calendar#Proleptic_Gregorian_calendar>
?

Agreed, my ignorance of calendars and ISO 8601 is overwhelming. I will
remedy that ignorance when time permits.

Sometimes people, and APIs, do the right thing even if you don't tell
them to. Furthermore, it is not your job to tell the standard API
what to do, but the standard API's job to tell you what it actually
does. As long as it works as documented, then you have no legitimate
gripe.


"Recoverable" is an awful, terrible, vague, useless, unworthy and
ridiculous criterion for choosing between the two. Instead, consider
either
- RuntimeException for programmer error, checked exception for
environmental error, or
- RuntimeException to let a caller slide without a 'catch' clause,
checked exception to force the 'catch'.

Whatever criterion you use, it's going to be a matter of style. There
are entire APIs out there that refuse to throw checked exceptions by
dint of the API writers' philosophy, others that go hog-wild with
them. It's up to the API writer what they choose to impose.

Fair enough.

 

[Lew]

Lew wrote
Lew wrote

Surely one of the benefits of newsgroups is that they allow other people
to look at archived questions and learn from them. If the archived
materials are severely trimmed, that could make it much harder to learn
from.

It's the opposite. If the posts are not trimmed, then a researcher has to
wade through pages and pages of repeated information to get at the nugget they
seek.

And I don't suggest "severely" trimming the posts, I suggest *appropriately*
trimming the posts. For example, in this post I focus on the issue of
trimming posts. I include all the necessary context to make the conversation
explicable, but trimmed the parts that would have been irrelevant to the
subtopic. Now, reading this, ask yourself which is clearer. Is there
anything missing from this post that leaves you lost and wondering what we're
discussing? Is there anything extraneous that dilutes the focus?

If there is, then I goofed and you should point it out so that I can correct
my mistake.

 

[Arne Vajhøj]

Actually, I would but in other threads people have said they're leaving
theirs intact for the benefit of those using Google groups. Won't I be
preventing Google Groups users from benefitting from this discussion if I
trim my posts?

No.

GG understands the thread concept and are able to put posts
in their proper context.

And BTW you should keep the minimal context in your post - just
not everything.

Arne

 

[Arne Vajhøj]

The year 1 never happened either. Neither did the year 100. Are you
going to reject those years, too?

Of course it did.

If you want to know what happened then look at:

http://en.wikipedia.org/wiki/1
http://en.wikipedia.org/wiki/100

Just because the naming were invented later does
not mean that something did not exist.

Arne

 

[RedGrittyBrick]

As Lew suggests, No - trimming doesn't prevent people easily being able
to view the whole of any prior message (after all that's what the
references in the headers are for).

Google Groups users are not the only readers of this newsgroup. If
message headers are anything to go by, the majority of people first read
this newsgroup using something other than Google Groups.

Surely one of the benefits of newsgroups is that they allow other people
to look at archived questions and learn from them. If the archived
materials are severely trimmed, that could make it much harder to learn
from.

If I need to I can look at the whole thread in Google's archives (or
indeed several others) and see the whole thread. If the thread is
comparatively recent I would prefer to view the thread in my NNTP client
(Thunderbird).

Speaking only for myself, I prefer to read a series of short messages
with short selective quotations rather than a series of increasingly
lengthy messages each of which repeats everything I've already read.

Please reconsider.


"If you are sending a reply to a message or a posting be sure you
summarize the original at the top of the message, or include just
enough text of the original to give a context. This will make sure
readers understand when they start to read your response. Since
NetNews, especially, is proliferated by distributing the postings
from one host to another, it is possible to see a response to a
message before seeing the original. Giving context helps everyone.
But do not include the entire original! "

http://www.faqs.org/rfcs/rfc1855.html

 

[Lew]

Of course it did.

I agree with you. In fact, I was making the very same point you are.

I only point out that if year 0 didn't happen, then year 1 didn't
either. You can't take one and not the other. I was using "never
happened" in the same inaccurate and mistaken way that Rhino did, for
a /reductio ad absurdum/ argument.

Does nobody apply logic and rhetorical analysis any more?

If you want to know what happened then look at:

http://en.wikipedia.org/wiki/1 http://en.wikipedia.org/wiki/100

<http://en.wikipedia.org/wiki/0_(year)>

Just because the naming were invented later does
not mean that something did not exist.

Exactly so.

 

[Rhino]

Please reconsider.


"If you are sending a reply to a message or a posting be sure you
summarize the original at the top of the message, or include just
enough text of the original to give a context. This will make sure
readers understand when they start to read your response. Since
NetNews, especially, is proliferated by distributing the postings
from one host to another, it is possible to see a response to a
message before seeing the original. Giving context helps everyone.
But do not include the entire original! "

http://www.faqs.org/rfcs/rfc1855.html

I'm sold. In fact, I've been trimming my posts for years. I've only reduced
trimming recently because of the remarks I saw from someone who said
trimming made it harder for Google Groups users to follow the discussion.
Apparently, I misunderstood those remarks and it is not a problem after
all.

 

[Arne Vajhøj]

I agree with you. In fact, I was making the very same point you are.

I missed that part.

I only point out that if year 0 didn't happen, then year 1 didn't
either. You can't take one and not the other. I was using "never
happened" in the same inaccurate and mistaken way that Rhino did, for
a /reductio ad absurdum/ argument.

Does nobody apply logic and rhetorical analysis any more?

It is not a matter of rhetoric.

It is a matter of facts.

When applying our calendar system back in the past, then it goes
...., 2, 1, -1, -2, ... (no 0).

So year 1 exists but year 0 does not.

I assume it is related to the lack of zero in roman numbers.

But no matter why it is such, then it is how it is.

<http://en.wikipedia.org/wiki/0_(year)>

Please read the text.

<quote>
"Year zero" does not exist in the widely used Gregorian calendar or in
its predecessor, the Julian calendar. Under those systems, the year 1 BC
is followed by AD 1.
</quote>

We use GregorianCalender, so:

<quote>
However, there is a year zero in astronomical year numbering (where it
coincides with the Julian year 1 BC) and in ISO 8601:2004 (where it
coincides with the Gregorian year 1 BC) as well as in all Buddhist and
Hindu calendars.
</quote>

is of little relevance.

Arne

 

[Lew]

Please read the text.

<quote>
"Year zero" does not exist in the widely used Gregorian calendar or in
its predecessor, the Julian calendar. Under those systems, the year 1 BC
is followed by AD 1.
</quote>

We use GregorianCalender, so:

<quote>
However, there is a year zero in astronomical year numbering (where it
coincides with the Julian year 1 BC) and in ISO 8601:2004 (where it
coincides with the Gregorian year 1 BC) as well as in all Buddhist and
Hindu calendars.
</quote>

is of little relevance.

It's entirely relevant because the ISO 8601 version, the one that does have a
year 0, is the version implemented by java.util.Calendar.

I notice on the one hand you argue for projecting the system back to prior to
its invention, when you argue in favor of a year "one", but for not projecting
the system back when it justifies having a year "zero". That is inconsistent.

It depends on which version of the Gregorian calendar you use. Since this is
a Java discussion, I'm using the one that Java uses.

 

[Mike Schilling]

It's entirely relevant because the ISO 8601 version, the one that
does have a year 0, is the version implemented by java.util.Calendar.

From Wikipedia

The common BC/BCE notation, for dates that are before year 0001, is not
used. For instance, the year 3 BC can be denoted by ?0002.[6] (There is
a difference of 1 because the BC system has no year zero.)

So, yes, ISO 8601 has a year encoded by the digits 0000, but that year is 1
BC.