Post by Bent C Dalager Post by Lew
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
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.
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
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
Post by Bent C Dalager
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?
Post by Bent C Dalager
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.
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".