Exception Throwing, Catching, and Declaring

[Rashakil Fol]

From http://www.daniweb.com/forums/thread172120.html#post791196 :

On a side note, never throw exceptions from main(). Use a try-catch block.

Why?

[Ezzaral]

Mostly because there is nothing up the call stack to deal with it.

I guess it's just a pet peeve when I see that because too often you see students writing their entire program in main() and slapping a throws clause up there without even really knowing what it does or why they have to have it there (I literally heard "I was told I had to put that there to make it compile. I don't know what it's for."), rather than learning why a try-catch block is required around certain sections of code and how to write one.

[Rashakil Fol]

I'm not sure which is worse. Having students use throws clauses or having so-called professionals write

try
{
    ...
}
catch (Exception e)
{
    e.printStackTrace();  // or whatever it is
}

For that reason, I think encouraging people to mindlessly catch exceptions is worse than having them mindlessly throw exceptions.

[verruckt24]

Actually the decision whether to throw an exception should be made wisely. The reason the throw and throws concepts exists is that that when a programmer feels incapable of handling an exception himself then he can delegate the condition to the next higher level in hope that the caller of the method can handle it himself.
Whether throwing or taking care of the exception, the developer has to catch the exception first.

[masijade]

I'm not sure which is worse. Having students use throws clauses or having so-called professionals write

try
{
    ...
}
catch (Exception e)
{
    e.printStackTrace();  // or whatever it is
}

For that reason, I think encouraging people to mindlessly catch exceptions is worse than having them mindlessly throw exceptions.

And the "so-called" professionals (as you say), won't do that, unless they are still in early debugging stages. They will, at the very least, log the error using one of the many logging packages available, then actually (can you believe this) attempt to handle the situation in a reasonable manner, so that the program can either continue, or reset back to a previous state without the program crashing down around their ears.

There is a reason that certain methods throw catchable exceptions. It is because those are errors that are, conceivably, recoverable. Simply declaring your methods to throw Exception so that you don't have to deal with them is infantile and idiotic "programming". Not really programming, at all.

[~s.o.s~]

> Why?

Simply because end users of your application need no frigging stack traces. ;-)

It also seems to indicate that the programmer isn't very clear on the kind of contingencies that can arise in the application and he plans on getting away by either having a generic catch-all block or having main() method throw an exception in its declaration. Then again, the granularity and rigor with which exception handling is implemented depends on the scale/scope of the application in consideration so YMMV.

From a professional development viewpoint, exceptions are usually caught and an appropriate course of action is taken; if it's a valid business scenario which has caused the exception [i.e. a business exception], the user is presented with a meaningful message and a resolution for the same if possible. If it's an exception which isn't caused due to the violation of business scenario and can't be resolved by the user, the exception is logged at the same time presenting the user with an appropriate message. And finally comes a catch-all block which is guaranteed to catch any sort of nasty application behavior, log it and present the user with a generic "sorry for the inconvenience" message.

Of course, when developing frameworks and libraries, a few other things need to be kept in mind when designing the exception hierarchy and exception handling mechanism, but yes, that sort of sums it up. :-)