Anonymous
Unregistered
|
|
One day you'll discover that a resource could not be loaded.
All seems correct, but the thing just does not load sometimes.
Why is that ? You'll never know.
But I will tell you: you actually get OutOfMemoryException, but you are not aware of it, because you catch and ignore all exceptions in your code !
Catching all Exceptions and ignoring them is BAD, BAD, BAD !!!
|
vlad_roubtsov
member
Reged: 06/21/03
Posts: 169
|
|
Thanks for the feedback. A couple of counter-arguments:
(a) if the resource cannot be loaded, null is returned if THROW_ON_LOAD_FAILURE is false (to be consistent with ClassLoader.getResourceAsStream() behavior) and an exception is thrown if this flag is true. The only exception that is truly ignored in my code is the one resulting from in.close() -- I have yet to find a reason why not doing so would be useful in any shape or form.
(b) you may have noticed that people who write articles tend to simplify error handling in their posted code anyway: this is to keep things clear and focus on the subject matter instead of details of error handling. The code is not there to be used as is/literally with no changes anyway, but to be read, understood, and reused as fits best for your application.
|
Anonymous
Unregistered
|
|
I agree that the code needs to be focused on the problem at hand but should not ignore other facets in view. Hence ignoring exceptions in code is indeed bad and should be acknowledged.
|
Unregistered
|
|
I know it's an old post but... If the author really wanted to simplify the code - AND do the right thing at the same time - he should have not used the pointless checked exception handling at all. There is NO good way to use checked exceptions. Have a top-level handler for ALL unrecoverable exceptions, implement individual handlers for each error condition that is EXPECTED to happen according to the business requirements for your module - where it is appropriate to handle them, not at the source of the error. Make them runtime as well but expect them - b/c they represent legitimate use cases. If the error is not expected, it means your app has no alternative action for it in store, so let it propagate to the top-level catch that handles everything. Handling a specific checked exception is dangerous b/c it leaves a possibility of all other exceptions being not caught at all. Not to mention that most people have no idea what they are doing at all when they catch, swallow, or rethrow every damn checked exception, and what a mess that creates....urghhhh
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
