Why does Java require the throws clause? Good or bad language design?

[J.E. Roper]

There are always unchecked exceptions. But Alex is right, in many cases you
need or want to make the exception part of a method's interface, and declaring
it so is no different than declaring that a method, say, takes a String arg.
Does declaring method parameters place an "undue" burden on a programmer?

I agree with this position with both hands.

Exceptions can simplify the code but they have to be
fine grained and handles properly at each level.
By declaring that some method throws exception,
you force the upper layers of your code to handle
that exception, and you can, if you wish, handle
the same exception in that same method to display
some error message of final granularity, and then
rethrow that same exception to the higher level
to see if some operation can be retried or do all
the other things they do on the higher level.

Once i started introducing the exception mechanism
in some of old java code, i was unable to compile
the app for days, because of compiler errors
"exception is not handled".
But the more i worked on it, the better the end
results were.

Right now, the program handles just about any
error condition imaginable and displays/logs
the error messages of the most precise description,
plus, on the top of it, it can retry just about
any error condition imaginable, upto simply
turning the power switch off or unplugging your
network cable. As soon, as you plug it back in,
the program will try to redo the LAST operation
it was doing, without restarting the whole cycle
from the top.

Throws clause is probably one of the better benefits
of the entire exception mechanism. Yes, it forces you
to hancle those exceptions on the higher level,
but it all happens during the compile time, preventing
all sorts of error conditions imaginable in the run time.

The only thing i suggest in terms of using exceptions
mechanism in general, is to use fine enough granularity
exceptions and handle them on the most appropriate level.
This way, you have about the most powerful structure,
allowing you to display the error messages of the most
precistion and, at the same tim, try to recover just
about any operation imaginable.

The extreme case: use the exceptions everywhere,
is simply foolish. First of all, you need to understand
the very nature of exceptions and it is essentially
an equivalent of a goto statement, that totally screws
up your stack and throws your program into place
you could not have imagine.

Any program is a fine mix of conditional code
and exceptions. Yes, purely conditional code approach
is way too messy as just after about any call,
you'd have to check on results of it. Otherwise,
you can not be certain that you can proceed,
which ends up in large amounts of unnecessary code
compared to properly used exceptions.

But...

You can't just get away from conditional code,
because it is the VERY NATURE of a program,
which is logic, and logic, its turn, is a conglomeration
of ifs and buts.

If you don't have those ifs and buts,
you'll end up with the most rigid and inflexible,
totalitarian system, forcing users to do things
he could not have imagine in his wildest dreams
he has to EVER do, going to the point of obscene
by requiring you to reboot your box in some extreme
instances.

Just because those masters of delusion
do not think that using fine grained ifs and buts
you'll achieve the most flexible and most pleasant
and comfortable environment for the USER,
which is what your entire app is there for on the
first place.

Well, you could always just write
public void foo(Object... args)
to get rid of that particular burden :-)

Is it supposed to be a joke?

And, of course,
public void foo(Object... args) throws Throwable
may be just the silver bullet we are looking for . . .

Just about the most foolish thing to do.
Once you make the declaration of this type,
you loose ALL the granularity of error condition
handling, and will NEVER be able to recover from
errors and attempt to redo only starting from
the error state in your program and continue on
after error condition has been removed,
which is what just about all real life apps do.

I have over a dozen of custom exceptions
derived at the most fine grained level of
standard exceptions, and handle all the exceptions
starting from the most fine grained
and going upto Exception level itself,
which means that you basically have a fatal error.
It means you have an error condition that was not
handled by ANY of your mechanism. It could be just
about the most innocent operation such as division
by 0, which could be properly handled and the
default values substituted for the error values
and the program could keep crunching along.

Summary:
You create a number of custom exceptions with fine
enough granularity to report/handle just about
ANY error condition imaginable, even in your wildest
dreams, and giving you the most precise scope of
error condition that could be handle locally
to provide the most precise and detailed error
messages or attempt to recover.

You HANDLE those exceptions starting from the most
fine grained level. You may have several levels
of catch blocks and act upon different exceptions
differently. In some cases, the operation could
be recovered by simply restarting the local level
of it. In other cases, the result could be more
brutal, in cases where you lost connection to the net,
or things like that, in which case you'd have to
retry going from higher levels,
and in some cases, those errors could be equivalent
to fatal, in which case you have to decide to either
stop the program completely, close some frames,
or restart it from the top.

"THATs the way you do it".

Good luck.

Cheers
Bent D

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sharon's Top Aide 'Sure World War III Is Coming'
From MER - Mid-East Realities
MiddleEast.Org 11-15-3
http://www.rense.com/general44/warr.htm

"Where the CIA goes, the Mossad goes as well.

Israeli and American interests have come together in the
dominance of the Central Asian region and therefore,
so have liberal ideology, the Beltway set, neo-conservatism,
Ivy League eggheads, Christian Zionism,

the Rothschilds and the American media.

Afghanistan through the Caspian Sea through to Georgia, Azerbaijan
and into the Balkans (not to mention pipelines leading to
oil-hungry China), have become one single theater of war over
trillions of dollars in oil and gas wealth, incorporating every
single power center in global politics.

The battle against the New World Order
is being decided in Moscow."

[Robert]

And, of course,
public void foo(Object... args) throws Throwable
may be just the silver bullet we are looking for . . .

It is true that this removes the effort of changing the declaratiens in
response to refactoring, but Java will still impose burdens on the
programmer. First, they have to actually type "Object" before every
argument and "throws Throwable" after every method declaration.

throws Throwable means your very design is incorrect
as you are entirely missing the granularity of your errors.
You'll never be able to successfuly recover
and forget about reattempting the operation
on a fine grained level as you will be thrown
several layers up.

Secondly, if you actually want to use these arguments and throwables,
you will have to downcast them to another class, because Object and
Throwable probably don't have the methods and fields you need. This
requires more typing. It also incurs a performance penalty, because the
casts will be checked at run time. In the end, you get the worst of
dynamic typing and the worst of mandatory declarations, all in one
program.

A BASIC rule in object oriented programming:

DO NOT USE CASTS.
Unless it is absolutely unavoidable.

Regards,
Bob

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"The most important job is not to be governor,
or first lady in my case."

--- Adolph Bush,
Pella, Iowa,
as quoted by the San Antonio Express-News, Jan. 30, 2000

[Little Bimbo]

And, of course,
public void foo(Object... args) throws Throwable
may be just the silver bullet we are looking for . . .

In the end, you get the worst of
dynamic typing and the worst of mandatory declarations, all in one
program.

Which is why newsgroup readers have to watch out for humorous replies, and not
try actually to implement them.

I agree with both hands.
These jokers are nothing more than noise makers,
having nothing to contribute of just about ANY value
beyond their "smart ass" image.

And on a technical group, it isn't even laughable.

- Lew

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
In 1920, Winston Churchill made a distinction between national and
"International Jews." He said the latter are behind "a worldwide
conspiracy for the overthrow of civilization and the reconstitution of
society on the basis of arrested development, of envious malevolence,
and impossible equality..."

[Endora]

And, of course,
public void foo(Object... args) throws Throwable
may be just the silver bullet we are looking for . . .

In the end, you get the worst of
dynamic typing and the worst of mandatory declarations, all in one
program.

Which is why newsgroup readers have to watch out for humorous replies, and
not try actually to implement them.

Point taken.
On the other hand, people do actually write code like that. Well.
perhaps not "throws Throwable", but certainly "throws Exception".

Not much different from throws Throwable
as you loose any and all the precision.
Basically, your program is screwed beyond repair
and the entire exceptions mechanism needs to be redesigned.

And
anyone who has been programming in Java for some time will have seen the
likes of
void add(Object o) ...
and
((SomeClass) someContainer.get(someKey)).someMethod(...)
It's not just misguided programmers that write such code; Java was full
of it before the type system overhaul.
Regards,
Bob

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Many of the punditry -- of course, not you (laughter) --
but other punditry were quick to say,
no one is going to follow the United States of America.

--- Adolph Bush,
"Washington, D.C., Jan. 21, 2003

[I.di Vinci-Fyfe]

And, of course,
public void foo(Object... args) throws Throwable
may be just the silver bullet we are looking for . . .

In the end, you get the worst of
dynamic typing and the worst of mandatory declarations, all in one
program.

Which is why newsgroup readers have to watch out for humorous replies, and not
try actually to implement them.

I agree with both hands.
These jokers are nothing more than noise makers,
having nothing to contribute of just about ANY value
beyond their "smart ass" image.

And on a technical group, it isn't even laughable.

- Lew

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Government is not reason, it is not eloquence.
It is a force, like fire, a dangerous servant
and a terrible master."

--- George Washington.

[Upset Cockroach]

There are always unchecked exceptions. But Alex is right, in many cases you
need or want to make the exception part of a method's interface, and declaring
it so is no different than declaring that a method, say, takes a String arg.
Does declaring method parameters place an "undue" burden on a programmer?

I agree with this position with both hands.

Exceptions can simplify the code but they have to be
fine grained and handles properly at each level.
By declaring that some method throws exception,
you force the upper layers of your code to handle
that exception, and you can, if you wish, handle
the same exception in that same method to display
some error message of final granularity, and then
rethrow that same exception to the higher level
to see if some operation can be retried or do all
the other things they do on the higher level.

Once i started introducing the exception mechanism
in some of old java code, i was unable to compile
the app for days, because of compiler errors
"exception is not handled".
But the more i worked on it, the better the end
results were.

Right now, the program handles just about any
error condition imaginable and displays/logs
the error messages of the most precise description,
plus, on the top of it, it can retry just about
any error condition imaginable, upto simply
turning the power switch off or unplugging your
network cable. As soon, as you plug it back in,
the program will try to redo the LAST operation
it was doing, without restarting the whole cycle
from the top.

Throws clause is probably one of the better benefits
of the entire exception mechanism. Yes, it forces you
to hancle those exceptions on the higher level,
but it all happens during the compile time, preventing
all sorts of error conditions imaginable in the run time.

The only thing i suggest in terms of using exceptions
mechanism in general, is to use fine enough granularity
exceptions and handle them on the most appropriate level.
This way, you have about the most powerful structure,
allowing you to display the error messages of the most
precistion and, at the same tim, try to recover just
about any operation imaginable.

The extreme case: use the exceptions everywhere,
is simply foolish. First of all, you need to understand
the very nature of exceptions and it is essentially
an equivalent of a goto statement, that totally screws
up your stack and throws your program into place
you could not have imagine.

Any program is a fine mix of conditional code
and exceptions. Yes, purely conditional code approach
is way too messy as just after about any call,
you'd have to check on results of it. Otherwise,
you can not be certain that you can proceed,
which ends up in large amounts of unnecessary code
compared to properly used exceptions.

But...

You can't just get away from conditional code,
because it is the VERY NATURE of a program,
which is logic, and logic, its turn, is a conglomeration
of ifs and buts.

If you don't have those ifs and buts,
you'll end up with the most rigid and inflexible,
totalitarian system, forcing users to do things
he could not have imagine in his wildest dreams
he has to EVER do, going to the point of obscene
by requiring you to reboot your box in some extreme
instances.

Just because those masters of delusion
do not think that using fine grained ifs and buts
you'll achieve the most flexible and most pleasant
and comfortable environment for the USER,
which is what your entire app is there for on the
first place.

Well, you could always just write
public void foo(Object... args)
to get rid of that particular burden :-)

Is it supposed to be a joke?

And, of course,
public void foo(Object... args) throws Throwable
may be just the silver bullet we are looking for . . .

Just about the most foolish thing to do.
Once you make the declaration of this type,
you loose ALL the granularity of error condition
handling, and will NEVER be able to recover from
errors and attempt to redo only starting from
the error state in your program and continue on
after error condition has been removed,
which is what just about all real life apps do.

I have over a dozen of custom exceptions
derived at the most fine grained level of
standard exceptions, and handle all the exceptions
starting from the most fine grained
and going upto Exception level itself,
which means that you basically have a fatal error.
It means you have an error condition that was not
handled by ANY of your mechanism. It could be just
about the most innocent operation such as division
by 0, which could be properly handled and the
default values substituted for the error values
and the program could keep crunching along.

Summary:
You create a number of custom exceptions with fine
enough granularity to report/handle just about
ANY error condition imaginable, even in your wildest
dreams, and giving you the most precise scope of
error condition that could be handle locally
to provide the most precise and detailed error
messages or attempt to recover.

You HANDLE those exceptions starting from the most
fine grained level. You may have several levels
of catch blocks and act upon different exceptions
differently. In some cases, the operation could
be recovered by simply restarting the local level
of it. In other cases, the result could be more
brutal, in cases where you lost connection to the net,
or things like that, in which case you'd have to
retry going from higher levels,
and in some cases, those errors could be equivalent
to fatal, in which case you have to decide to either
stop the program completely, close some frames,
or restart it from the top.

"THATs the way you do it".

Good luck.

Cheers
Bent D

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Herman Goering, president of the Reichstag,
Nazi Party, and Luftwaffe Commander in Chief:

"Naturally the common people don't want war:
Neither in Russia, nor in England, nor for that matter in Germany.
That is understood.

But, after all, it is the leaders of the country
who determine the policy and it is always a simple matter
to drag the people along, whether it is a democracy,
or a fascist dictatorship, or a parliament,
or a communist dictatorship.

Voice or no voice, the people can always be brought to
the bidding of the leaders. That is easy. All you have
to do is tell them they are being attacked, and denounce
the peacemakers for lack of patriotism and exposing the
country to danger. It works the same in any country."

--- Herman Goering (second in command to Adolf Hitler)
at the Nuremberg Trials

[t***@houston.rr.com]

And, of course,
public void foo(Object... args) throws Throwable
may be just the silver bullet we are looking for . . .

It is true that this removes the effort of changing the declaratiens in
response to refactoring, but Java will still impose burdens on the
programmer. First, they have to actually type "Object" before every
argument and "throws Throwable" after every method declaration.

throws Throwable means your very design is incorrect
as you are entirely missing the granularity of your errors.
You'll never be able to successfuly recover
and forget about reattempting the operation
on a fine grained level as you will be thrown
several layers up.

Secondly, if you actually want to use these arguments and throwables,
you will have to downcast them to another class, because Object and
Throwable probably don't have the methods and fields you need. This
requires more typing. It also incurs a performance penalty, because the
casts will be checked at run time. In the end, you get the worst of
dynamic typing and the worst of mandatory declarations, all in one
program.

A BASIC rule in object oriented programming:

DO NOT USE CASTS.
Unless it is absolutely unavoidable.

Regards,
Bob

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"There's not going to be enough people in the system
to take advantage of people like me."

--- Adolph Bush,
On the coming Social Security crisis;
Wilton, Conn.; June 9, 2000 (Thanks to Andy Mais.)

[Harvey]

And, of course,
public void foo(Object... args) throws Throwable
may be just the silver bullet we are looking for . . .

In the end, you get the worst of
dynamic typing and the worst of mandatory declarations, all in one
program.

Which is why newsgroup readers have to watch out for humorous replies, and
not try actually to implement them.

Point taken.
On the other hand, people do actually write code like that. Well.
perhaps not "throws Throwable", but certainly "throws Exception".

Not much different from throws Throwable
as you loose any and all the precision.
Basically, your program is screwed beyond repair
and the entire exceptions mechanism needs to be redesigned.

And
anyone who has been programming in Java for some time will have seen the
likes of
void add(Object o) ...
and
((SomeClass) someContainer.get(someKey)).someMethod(...)
It's not just misguided programmers that write such code; Java was full
of it before the type system overhaul.
Regards,
Bob

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"It would be a mistake for the United States Senate
to allow any kind of human cloning to come out of
that chamber."

--- Adolph Bush,
Washington, D.C., April 10, 2002

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This is just a reminder.
It is not an emergency yet.
Were it actual emergency, you wouldn't be able to read this.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -