Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.help > #628

Re: Some same exceptions used in a given file

Show all headers | View raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 4/23/2011 6:00 PM, Merciadri Luca wrote:
>
>> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>>
>>> On 4/23/2011 1:08 PM, Merciadri Luca wrote:
>>>> In some of my code files, I've got the following catch block
>>>>
>>>> ==
>>>>           catch (IOException cantOpenFile)
>>>>               {
>>>>                   System.err.println("Can't open " + inputFilename + ".");
>>>>                   System.exit(1);
>>>>               }
>>>> ==
>>>> more than once, but at different places in the file. Is it possible to
>>>> define this somewhere so that I can directly catch the exception with
>>>> the two given commands? (Just as one would define his own exception.)
>>>
>>>      Could you give an example of what you're trying to do?  (The
>>> above isn't sufficiently informative.)
>>
>> Thanks for the answers. Sure I can provide more details. Let us
>> consider the following constructor:
>>
>> ==
>>     public FileStream ()
>>      {
>>          try
>>              {
>>                  outputFile = new BufferedWriter(new FileWriter("hello.txt"));
>>              }
>>          catch (IOException cantWriteInFile)
>>              {
>>                  System.out.println("Impossible to write (in) hello.txt.");
>>                  System.exit(1);
>>              }
>>      }
>> ==
>> You saw that I had to catch an IOException, as expected when dealing
>> with a BufferedWriter.
>>
>> Now, in a function of the same class of the constructor (class
>> FileStream), I need to write in the output file. As a result, I've got
>>
>> ==
>> public void write (String outputText)
>> {
>>          try
>>              {
>>                  outputFile.write(outputText);
>>                  outputFile.close();
>>              }
>>          catch (IOException cantWriteInFile)
>>              {
>>                  System.out.println("Impossible to write (in) hello.txt.");
>>                  System.exit(1);
>>              }
>> }
>> ==
>>
>> You directly notice that the two catch blocks are identical. As a
>> result, I'd like to do something like this (in pseudocode):
>>
>> ==
>>    public FileStream ()
>>      {
>>          try
>>              {
>>                  outputFile = new BufferedWriter(new FileWriter("hello.txt"));
>>              }
>>          catch (IOException cantWriteInFile);
>>      }
>> ==
>> 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.
>
>     See Stefan Ram's answer.
>
>     However, it seems to me that what you want to do reeks of bad
> design.  For many simple programs it's true that an I/O error is
> reason for termination -- but even for simple programs it is *not*
> a good idea for low-level code to yank the rug out from beneath the
> rest of the program.  The low-level code is not aware of the wider
> context in which it's being used, and is not in a good position to
> make global decisions about the program's state and fate.
>
>     Poor analogy: You leave your coat at the cleaners', and they
> notice that one of the buttons has come off.  "Imperfect coat," they
> say, and burn it: They're sure you wouldn't want to wear an imperfect
> coat, and they think they're doing you a favor by relieving you of the
> expense of cleaning it.  What they didn't know is that you've got a
> needle and thread and are fully able to reattach the button -- except
> that the coat's been burned.  They made a global decision on the basis
> of a local context.
>
>     If you can't do anything constructive about an exception, the
> best policy is usually to re-throw it, or not to catch it in the
> first place.  Change your constructor and method to
>
> 	public FileStream throws IOException { ... }
>
> 	public void write(String text) throws IOException { ... }
>
> If the caller can do something constructive (try a different
> file, perhaps?), the caller can catch your IOException and take
> a different course.  If the caller is helpless, it, too, can let
> the exception propagate outwards to its caller, and to callers at
> higher and higher levels.  If nobody ever catches it, that means
> nobody was prepared to deal with the situation and the program will
> terminate anyhow.  But if somebody along the way *can* cope with
> the problem, you've allowed them to do so instead of burning the coat.

Thanks for the example. And now if another method of the same class
throws also an IOException, but whose action needs not to be the same?

For example, how would I convert

==
public void foo
{
 try
 {
 // ...
 }

 catch (IOException problem1)
 {

 }

}

public void bar
{
 try
 {
 // ...
 }

 catch (IOException problem2)
 {

 }

}
==

?

I might do

==
public void foo throws IOException
{
 // ...
}

public void bar throws IOException
{
 // ...
}
==

and then catch the exception in the caller, but how do I differentiate
from problem1 to problem2? Sorry for this silly question, but it seems
not that habitual regarding Google answers on this.

- -- 
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
- -- 

If you want to judge a man's character, give him power.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAk2zXsYACgkQM0LLzLt8Mhxe/wCeOcSgY9zphrTXVL7ZUrPEhIHT
vD8An1zp+aFpAzMbsXqIBDie503qsTEF
=yCsK
-----END PGP SIGNATURE-----

Back to comp.lang.java.help | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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