Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > To wrap or not to wrap?

Reply
Thread Tools

To wrap or not to wrap?

 
 
Aaron Fude
Guest
Posts: n/a
 
      05-08-2008
Hi,

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.

Thanks for your opinions!

Aaron
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      05-08-2008
Aaron Fude <(E-Mail Removed)> writes:
>These functions catch exceptions and return null


You must like the classic C idiom

if( f = fopen( "alpha", "r" ))
{ use( f );
close( f ); }
else
{ handle_failure( "alpha", "r" ); }

more than exception idioms like

try
{ f = fopen( "alpha", "r" );
try
{ use( f ); }
finally
{ close( f ); }}
catch( final Exception exception )
{ handleFailure( "alpha", "r", exception ); }

I also like structured programing, and it is not easy
for me to cope with the exception style. I hope that
I at least have done the above translation correctly.

The above code already looks complicated, but it becomes even
more complicated, when you need to obtain and release
/multiple/ resources. This should be done as a kind of
transaction: When you need n resources, you might have
obtained m already (m < n), but the next attempt might
fail. Then you need to return to a orderly state and
release exactly those resources that have been allocated
so far and report the whole operation to be failed. So
the above patterns need to be nested, which makes the
result even more complicated.

I have invented another style, that use an object to handle
control flow and should take care of the problem to allocate
multiple resources

Here is an example (explanation follows below):

public void digest( final java.io.File file )
{ final de.dclj.ram.system.program.Program program
= new de.dclj.ram.system.program.Program();
try
{
final java.io.FileInputStream fileInputStream =
program.'new java.io.FileInputStream'( file ); /* first attempt */

final java.io.BufferedInputStream bufferedInputStream =
program.'new java.io.BufferedInputStream'( fileInputStream );

final java.security.MessageDigest messageDigest =
program.'new java.security.MessageDigest'( type );

if( program.succeeded() )
{ this.process( bufferedInputStream, messageDigest ); }
else
{ java.lang.System.out.println( program.'opening exceptions'() ); }}

finally
{ program.close();
if( !program.closed() )
{ java.lang.System.out.println( program.'closing exceptions'() ); }}}}

A preprocessor converts everything withing single quotes to
Java names. This is not necessary for this approach, but just
an additional convenience.

The operation »this.process« needs three resources: A file
input stream, a buffered input stream and a message digest.

The object »program« has operations to request the allocations
needed. If the first attempt fails, it will skip the next two
attempts and »program.succeeded()« will be false. The client
above does not have to use »if« or »try« for each attempt.
He can request the exceptions from the program object.

»program.close()« will then close exactly those resources that
have been obtained successfully before, because »program« has
kept track of the release operations required to release
everything that has been allocated successfully using this
program object.

Drawback: Each type of resource needs a special implementation
in »de.dclj.ram.system.program.Program«, and right now there are
only few types implemented. I will add additional code as I
need it. See also:

http://www.purl.org/stefan_ram/html/...m/Program.html

(with links to the source code.) This is part of the library

http://www.purl.org/stefan_ram/pub/ram-jar

 
Reply With Quote
 
 
 
 
Arne Vajhøj
Guest
Posts: n/a
 
      05-08-2008
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
 
Reply With Quote
 
Aaron Fude
Guest
Posts: n/a
 
      05-08-2008
On May 8, 7:13*pm, Arne Vajhøj <(E-Mail Removed)> 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?
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      05-08-2008
Aaron Fude wrote:
> On May 8, 7:13 pm, Arne Vajhøj <(E-Mail Removed)> 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.

>
> 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?


Testing for return values in a deep call stack adds lots of clutter to
the code.

Exceptions was invented to avoid that.

So catching the exception at the low level and convert to a return
value is a bad idea.

Arne
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      05-08-2008
On Thu, 8 May 2008, 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.


What everyone else said. Exceptions are a good way to do error handling.
Null returns are not. You're shooting yourself in the foot.

tom

--
For the first few years I ate lunch with he mathematicians. I soon found
that they were more interested in fun and games than in serious work,
so I shifted to eating with the physics table. There I stayed for a
number of years until the Nobel Prize, promotions, and offers from
other companies, removed most of the interesting people. So I shifted
to the corresponding chemistry table where I had a friend. At first I
asked what were the important problems in chemistry, then what important
problems they were working on, or problems that might lead to important
results. One day I asked, "if what they were working on was not important,
and was not likely to lead to important things, they why were they working
on them?" After that I had to eat with the engineers! -- R. W. Hamming
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      05-08-2008
Aaron Fude <(E-Mail Removed)> writes:
>I kind of do. I capture the exception within the function and print
>the error message.


Printing is not a general solution, because it means that
these functions can only be used in console programs and when
printing each exception is wanted.

But the exceptions will not be visible when the program is
using a GUI oder a speech interface. And it will be difficult
to log the exceptions.

This explains, why Java does not uses this as a »general
solution«.

General operations should not assume that the application
has a specific interface and just return values, they should
not do any I/O unless this happens to be their purpose.

 
Reply With Quote
 
Patricia Shanahan
Guest
Posts: n/a
 
      05-09-2008
Aaron Fude wrote:
> Hi,
>
> 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.


Situations in which I would return null due to an exception are really
rare. More usually, either the exception is a disaster and must be let
flow up the stack to something that can deal with it definitively, or
there is a useful value that can be used, and that should be returned.

In letting exceptions flow up the stack, I do sometimes wrap them in
other exceptions. For example, I might wrap a NumberFormatException in
an InputValidationException, adding data such as a line number and
position in line of the string I tried, and failed, to parse as a number.

Patricia
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      05-09-2008
On Thu, 8 May 2008 15:19:42 -0700 (PDT), Aaron Fude
<(E-Mail Removed)> wrote, quoted or indirectly quoted someone who
said :

>etc. These functions catch exceptions and return null if something
>goes wrong. I have other functoins that, for example, load database
>queries into maps.


You are thinking in C. The advantage of exceptions is you can handle
them at any level that is convenient. By returning null, you force an
explicit check, and you must handle the problem then and there or else
explicitly pass the problem up the call chain.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Chronic Philharmonic
Guest
Posts: n/a
 
      05-09-2008


"Aaron Fude" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On May 8, 7:13 pm, Arne Vajhøj <(E-Mail Removed)> 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.



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Wrap computer components in bubble wrap? Ickshka Computer Support 7 05-05-2006 05:54 PM
asp Lable does not wrap at new line. Nalaka ASP .Net 8 12-06-2005 07:15 PM
Making DataGrid Items not wrap text Dan ASP .Net 2 03-02-2004 06:47 PM
Text::Wrap::wrap difference Art Werschulz Perl Misc 1 09-25-2003 06:15 PM
Text::Wrap::wrap difference Art Werschulz Perl Misc 0 09-22-2003 02:36 PM



Advertisments