Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.help > #632
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Newsgroups | comp.lang.java.help |
| Subject | Re: Some same exceptions used in a given file |
| References | <87r58s28w3.fsf@merciadriluca-station.MERCIADRILUCA> <iov6eu$ps5$1@dont-email.me> <871v0smxvr.fsf@merciadriluca-station.MERCIADRILUCA> |
| Message-ID | <5_Ksp.39651$0s5.24380@newsfe17.iad> (permalink) |
| Organization | Public Usenet Newsgroup Access |
| Date | 2011-04-23 22:25 -0300 |
On 11-04-23 07:00 PM, Merciadri Luca wrote:
[ SNIP ]
> then, later in the file:
>
> ==
> public void write (String outputText)
> {
> try
> {
> outputFile.write(outputText);
> outputFile.close();
> }
> catch (IOException cantWriteInFile);
> }
> ==
> where IOException cantWriteInFile is defined in the class as
>
> ==
> System.out.println("Impossible to write (in) hello.txt.");
> System.exit(1);
> ==
>
> Is there a way to do this? It looks terribly bad to have the same
> catch code in two different methods.
>
Hi, Merciadri: these are OK questions, actually - for a few years down
the road, if you stick with Java. You've gotten good advice from the
other posters; let me add my few euros worth also.
A few years down the road, if you're still programming with Java, you'll
find that questions about System.exit and having "registered" common
exception handlers for certain exception types don't even occur to you.
Seriously.
For System.exit, unless you're writing standalone desktop applications
or Java servers, you won't even care. System.exit doesn't get used in
Java EE web apps, which is what a lot (most) of Java programmers do
these days. Nor do you care about this if you're writing a Java
library/framework, which is what a lot of other Java programmers do. For
people who do care, there is invariably a natural spot in your main()
where you stick the System.exit, and it falls out from good design.
That's the main point, that good design dictates these things. Other
posters are making this point. Rather than worry about cosmetics - and
your question about the above code really is about appearance - worry
about good encapsulation, good interfaces, good decisions about who
handles what exception, and then way later worry about making things pretty.
I'll make a couple of points about exception handling specifically. If
you find yourself with a class, or a set of classes in a package, where
you are catching a lot of the same exceptions (same cause, same type),
then you may have one of two types of design problem:
1. the actions that result in all these similar exceptions should really
be a single (or considerably) fewer actions in a more centralized spot; or
2. (and this is related) you've decided to let the wrong layer handle
the exceptions - throw them instead, and handle them in a more
centralized spot.
Once you've sorted this out, though, keep in mind - and I know this was
mentioned by others - that exception handling is a local thing. It may
seem like a cross-cutting concern, but it's really not (*). Once you've
decided to catch in a specific place, focus on the right thing to do for
that scenario. It's early days for you - it may seem like there's a lot
of duplication - but once things start falling into place you'll see
that duplication of code in catch clauses is not a major issue.
AHS
* More to the point, the correct way to take care of this is let the
exception go higher up the calling chain if there's a better place to
handle it.
--
Governor Thomas was so pleas'd with the Construction of this Stove, as
describ'd in it, that he offer'd to give me a Patent for the sole
Vending of them for a Term of Years; but I declin'd it from a Principle
which has ever weigh'd with me on such Occasions, viz. That as we enjoy
great Advantages from the Inventions of Others, we should be glad of an
Opportunity to serve others by any Invention of ours, and this we should
do freely and generously.
-- Benjamin Franklin
Back to comp.lang.java.help | Previous | Next — Previous in thread | Next in thread | Find similar
Some same exceptions used in a given file Merciadri Luca <Luca.Merciadri@student.ulg.ac.be> - 2011-04-23 19:08 +0200
Re: Some same exceptions used in a given file Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-04-23 14:40 -0400
Re: Some same exceptions used in a given file Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-04-23 16:23 -0400
Re: Some same exceptions used in a given file Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-04-23 17:23 -0300
Re: Some same exceptions used in a given file Merciadri Luca <Luca.Merciadri@student.ulg.ac.be> - 2011-04-24 00:00 +0200
Re: Some same exceptions used in a given file Lew <noone@lewscanon.com> - 2011-04-23 18:22 -0400
Re: Some same exceptions used in a given file Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-04-23 18:31 -0400
Re: Some same exceptions used in a given file Merciadri Luca <Luca.Merciadri@student.ulg.ac.be> - 2011-04-24 01:20 +0200
Re: Some same exceptions used in a given file Lew <noone@lewscanon.com> - 2011-04-23 20:19 -0400
Re: Some same exceptions used in a given file Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-04-23 22:25 -0300
Re: Some same exceptions used in a given file Merciadri Luca <Luca.Merciadri@student.ulg.ac.be> - 2011-04-24 09:24 +0200
Re: Some same exceptions used in a given file Patricia Shanahan <pats@acm.org> - 2011-04-23 13:48 -0700
Re: Some same exceptions used in a given file Merciadri Luca <Luca.Merciadri@student.ulg.ac.be> - 2011-04-24 09:34 +0200
Re: Some same exceptions used in a given file Lew <noone@lewscanon.com> - 2011-04-24 09:40 -0400
Re: Some same exceptions used in a given file Patricia Shanahan <pats@acm.org> - 2011-04-24 06:53 -0700
Re: Some same exceptions used in a given file Merciadri Luca <Luca.Merciadri@student.ulg.ac.be> - 2011-04-24 01:28 +0200
csiph-web