0

I've got the following method:

public T peek() throws StackEmptyException {
    Node<T> tracker = head; 
    while(tracker.getNext() != null) {
        tracker = tracker.getNext(); 
    }
    return tracker.getItem(); 
}

The problem is that when I try to do something like

int firstOne = stack.peek(); 

I get an unreported exception StackEmptyException and I have no idea what I'm doing wrong at this point. The StackEmptyException has been made in a separate class. Am I suppose to have this class extend that new exception class I made? So confused. Thoughts guys?

Racil Hilan
  • 24,690
  • 13
  • 50
  • 55
Vimzy
  • 1,871
  • 8
  • 30
  • 56
  • 1
    This has nothing to do with generics - it's just normal checked exceptions. See http://docs.oracle.com/javase/tutorial/essential/exceptions/ – Jon Skeet Mar 12 '14 at 06:52
  • Yeah, so why exactly is it reporting that when I compile it? – Vimzy Mar 12 '14 at 06:55
  • Because you have extended `Exception`, as such your exception is a checked exception. This means code using your method should catch it, or the method in which `.peek()` is used should `throws` it as well. – fge Mar 12 '14 at 06:57
  • Because it's a checked exception, and you're calling it from a method which neither catches it nor declares that it throws it. Please read the tutorial. – Jon Skeet Mar 12 '14 at 06:58
  • @fge but the peek() method does have a "throws" clause. Does that not satisfy the condition? Or do I need to use try/catch statements when invoking the stack.peek ? – Vimzy Mar 12 '14 at 07:00
  • No, that does not satisfy the condition for methods that _call_ this method. Such methods should try/catch or rethrow it (your choice). – fge Mar 12 '14 at 07:02

2 Answers2

2

Since StackEmptyException is an checked exception (which you shouldn't do in first place), you should handle that exception when invoking the peek() method. The rule is, either you should handle the exception or declare it to be thrown.

However, I would take a step back and change StackEmptyException to an Unchecked Exception. Then you wouldn't need to handle it or declare it as thrown.

Rohit Jain
  • 209,639
  • 45
  • 409
  • 525
  • " (which you shouldn't do in first place)" <-- why? – fge Mar 12 '14 at 06:55
  • This is an assignment, so I have no choice, but to do it the way they want me to. – Vimzy Mar 12 '14 at 06:55
  • So are you saying that I would have to use try/catch when declaring int firstOne = stack.peek(); ? – Vimzy Mar 12 '14 at 06:58
  • @Vimzy Yes. Either that, or declare it in `throws` clause of method. – Rohit Jain Mar 12 '14 at 07:05
  • @RohitJain But that's exactly what I've done. If you look at my method code above, I add the "throws" clause in the method declaration. I'm not understanding. I have to do that, and the try/catch? – Vimzy Mar 12 '14 at 07:11
  • @Vimzy Ok, how about showing us the method where you're invoking the `peek()` method? Post the actual code you've. – Rohit Jain Mar 12 '14 at 07:59
0

Checked exceptions (ie, a class which extends Exception but not RuntimeException or Error) thrown by a method should be handled by this method's caller, recursively so.

Here you have .peek() which throws, say, exception class E (bad name, but this is for illustration). You must do one of the following in a foo() method which calls .peek():

  • catch it, or
  • throw it again.

That is, either:

// catch
void foo()
{
    try {
        peek();
    } catch (E e) {
       // something
    }
}

or:

// throw
void foo() throws E
{
    peek();
}

You could even rethrow it:

// catch then rethrow
void foo() throws E
{
    try {
        peek();
    } catch (E e) {
        // something, then
        throw e;
    }
}
fge
  • 119,121
  • 33
  • 254
  • 329