"Aaron Fude" <aaronfude@[EMAIL PROTECTED]
> wrote in message
news:6ab8974f-11cf-4b7a-bcb2-99c865fb6c6f@[EMAIL PROTECTED]
> On May 8, 7:13 pm, Arne Vajhøj <a...@[EMAIL PROTECTED]
> wrote:
>> Aaron Fude wrote:
>> > In my personal development efforts, I frequently wrap basic java
>> > functionality. For example, I have a
>>
>> > String MyIO.urlToString(String url)
>>
>> > or
>>
>> > byte[] MIO.urlToBytes(String url)
>>
>> > etc. These functions catch exceptions and return null if something
>> > goes wrong. I have other functoins that, for example, load database
>> > queries into maps.
>>
>> > My gereneral questions are these. Does everybody pretty much end up
>> > writing convenience wrappers like these for themselves?. If yes, why
>> > aren't utilities like these commonly available as more or less
>> > standard libraries? And if no - why not? Is it a bad idea to use
these
>> > and is it for some reason better to, e.g., always form URL's, open
>> > connections, capture exceptions, etc.
>>
>> I think it is a bad idea.
>>
>> You should use the exception functionality as it is intended.
>>
>> Arne- Hide quoted text -
>>
>> - Show quoted text -
>
>
> I kind of do. I capture the exception within the function and print
> the error message. But wrapping this in a function in my project saves
> me hundreds of lines of code, enables me not to have to remember how
> things are done at the low level. For example, I have a function
> called void playSoundClip(String fileName) and BufferedImage[]
> loadImage(String fileName). I don't even remember the package that
> deals with playing audio and Eclipse finds my own function for me
> immediately.
> When you say "should" can you elaborate why. When could this lead to
> problem from the development point of view?
Returning null instead of the exception that was originally thrown
requires
the caller to check for null every time, or blindly use the null value
(usually causing a NullPointerException which is generally less
informative
when it occurs). Using exceptions correctly often results in less code,
because you can just plow ahead as if everything is fine, and catch the
exception where it makes sense in your code (where you can recover from
it),
or just let it fly if you can't recover from it. That way, your
application
logic is uncluttered with error handling code, and all the error handling
code is in one place (in the catch block). There are always exceptions to
this rule (no pun intended):
1. Exceptions should be, er, exceptional. If they happen all the time, or
very frequently, they're not exceptional, and you should investigate
whether
can detect the conditions that are causing the exceptions, and try to
prevent them from happening in the first place. Otherwise, throwing and
handling a flurry of exceptions could introduce a performance penalty.
2. If the code is poorly organized, the exception handling code could be
just as intrusive as the constant checking for error return values. Well
organized exception handling is a bit of an art that you learn by
experience.
Finally, there is nothing wrong with wrapping other method calls if there
is
a sequence of instructions that you use repeatedly from all over your
application. In fact, that is a situation that screams for a subroutine.
You
should totally do that.
|
