0

My client code:

public static void inputFiles()
{

  File inputFile = new File("colors2.txt");
  if (!inputFile.exists()) {  
        throw new FileNotFoundException(("File not found"));  
   }  
  ColorSet colorSetter = new ColorSet(inputFile);
}

My Supplier class constructor:

public ColorSet(File source) throws FileNotFoundException
{
   if (!source.exists()) {  
        throw new FileNotFoundException(("File not found"));  
   }  
    colorInput = source;
}

I keep on getting "unreported exception java.io FileNotFoundException; must be caught or declared to be thrown"

I've try catching it in the client method, but it's telling me it can't be called in the body block, maybe I'm doing it wrong?

shift66
  • 11,760
  • 13
  • 50
  • 83
pood
  • 73
  • 1
  • 7

4 Answers4

2

The reason it is complaining is that it wants inputFiles() throws FileNotFoundException.

That said, if you have it in the constructor of ColorSet, I am curious as to why you need it in inputFiles, and why inputFiles is plural even though it is only inputting one file.

Your alternate solution is not to throw FileNotFoundException and catch the Exception in the constructor of ColorSet in the inputFiles method.

cwallenpoole
  • 79,954
  • 26
  • 128
  • 166
2

If you are throwing a checked exception in java you need to declare it in your method signature. Also if you call a method (or constructor) that throws a checked exception then you will either need to handle that exception in a try-catch block like:

try {
    ColorSet colorSetter = new ColorSet(inputFile);
} catch (FileNotFoundException fnfe) {
    // do something sensible with the exception.
}

If you were to throw a runtime exception instead you do not need to declare that your methods throws them. In this case I'd suggest you use IllegalArgumentException since it seems you are checking if the argument provided to your methods are valid.

Also note that it's often considered bad to throw an exception from a constructor. Thought that's more rule of thumb stuff...

Emil L
  • 20,219
  • 3
  • 44
  • 65
  • I didn't know you shouldn't throw in the constructor. We're suppose to use that exact constructor (from CS proff) – pood Feb 17 '12 at 18:27
  • There can be a few problems with constructors and exceptions: http://stackoverflow.com/a/1371559/355499 , http://futuretask.blogspot.com/2006/05/java-tip-10-constructor-exceptions-are.html – Emil L Feb 17 '12 at 19:53
  • 1
    *Some people* consider it bad for a constructor to throw exceptions. However, there are many examples of Java SE standard classes that do exactly that. For example, all of the most of the constructors that create input / output streams, readers and writers are declared to throw `IOException`. There is nothing fundamentally wrong with doing it. – Stephen C Aug 28 '22 at 11:32
1

inputFiles() has to declare it as well

Kai Sternad
  • 22,214
  • 7
  • 47
  • 42
0

As said previously, you need to have inputFiles() throw it as well with your current approach.

I'd suggest however, having the just the constructor for ColorSet throw the exception and then catch the exception in inputFiles() or just let inputFiles() pass the exception to it's caller (without having file checking code in inputFiles() method). This approach removes duplicated code, and ensures that the exception is thrown any time someone creates the ColorSet object still.

dsingleton
  • 976
  • 6
  • 7