Throw Keyword in Function'S Signature

Throw keyword in function's signature

No, it is not considered good practice. On the contrary, it is generally considered a bad idea.

http://www.gotw.ca/publications/mill22.htm goes into a lot more detail about why, but the problem is partly that the compiler is unable to enforce this, so it has to be checked at runtime, which is usually undesirable. And it is not well supported in any case. (MSVC ignores exception specifications, except throw(), which it interprets as a guarantee that no exception will be thrown.

What is the purpose of using throw after function signature in c++?

throw() in the function signature specifies the exceptions a function may throw.

Example:

void foo() throw(std::runtime_error, std::logic_error);

throw() with no arguments means the function throws no exceptions

Exception specification is deprecated and its usage is not recommended.

Difference between Throws in method signature and Throw Statements in Java

You are pretty much right on. Except for one thing I'll mention in a bit.

throws is as much a part of the method API as the name and the parameters. Clients know if they call that method, they need to handle that exception--by simply throwing it also or by catching it and handling it (which may in fact entail the throwing of another exception wrapping the original). throws is addressed at compile time.

throw is the actual act of letting the runtime know something bad happened--that the exceptional condition we were worried about has in fact taken place. So it needs to be dealt with at runtime.

But you weren't quite right when you said, "Throws in method signature should always appear if there exist a throw statement in the method." That is often true but not always. I could also call another method that throws an exception within my method, and if I don't catch it, my method needs to throw it. In that case, there is no explicit throw of the same exception by me.

The final point is that you only need to declare an exception in throws when the exception is a checked exception--meaning it is from the other side of the Exception class hierarchy from RuntimeException. Common checked exceptions are IOException and SQLException. Checked exceptions must be listed in the throws part of the method signature if you don't handle them yourself. Anything subclassing RuntimeException--like NoSuchElementException in your example and also the hated NullPointerException--is an unchecked exception and doesn't have to be caught or thrown or anything.

Typically, you use checked exceptions for recoverable problems (where the client knows what can happen and can gracefully handle the problem and move on) and unchecked exceptions for catastrophic problems (like can't connect to the database).

If you can get past all the AOP stuff, this is a great discussion of how you use checked and unchecked exceptions effectively.

Why is throws part of the method signature

The throws part does not indicate that the method is required to throw the mentioned exception(s), not even at particular occasions. It only tells that the function is allowed to do so.

Including throws UnsupportedOperationException will consequently not mean that the method is unsupported. Besides the UnsupportedOperationException is a RuntimeException so a method may throw that anyway.

Now for the reason one would require it in the signature of the method, it boils down to the ability to have checked exceptions at all. For the compiler to be able to decide if a method can only throw the specified exceptions it must be able to decide that the methods that it calls can't throw uncaught exceptions.

This means for example that overriding a method means that you can't add exceptions that might be thrown, otherwise you would break the possibility to verify that a method that calls that method can't throw anything else than it has specified. The other way around would be possible (but I'm not sure if Java supports that), overriding a method that may throw with one that may not throw.

So for example:

class B {
    int fubar(int) throws ExceptionA {
    }

    int frob(int) throws ExceptionA {
         return fubar(int);
    }
}

class D extends B {
    int fubar(int) throws ExceptionB {
    }
}
    

Now frob is specified to possibly throw only ExceptionA, but in calling this.fubar it would open the possibility that something else is thrown, but fubar is defined to possibly only throw ExceptionA. That's why the D.fubar is an invalid override since that would open up the possibility that this.fubar actually throws ExceptionB and the compiler wouldn't be able to guarantee that frob doesn't throw ExceptionB.

Throws keyword in C++

You haven't defined StackException anywhere in your program. You have to create it yourself. Also strip throws Exception from your function signature, since you never defined that type either (and it's called throw Exception).

Furthermore it isn't really necessary to state what exceptions are possible in the signature, but it's better to state that a function will never throw (using noexcept in C++11). State possible exceptions in the documentation. Furthermore, you missed a possible bad_alloc.

All in all, strip all your code and use std::stack from <stack> and strip those C libraries. However, here is a example how you could do it:

template<class T>
class Stack {
private:
    int max;
    int top;
    T * items;
public:
    struct out_of_space{};
    struct empty_stack{};
    Stack(int size) {
        if(size)
            max = size;
        top = -1;
        items = new T[max];
    }
    ~Stack(){delete[] items;}

    void push(const T & data){
        if(full()) {
            throw out_of_space();
        }
        items[++top] = data;
    }
    T pop(){
        if(empty()){
            throw empty_stack();
        }
        return items[top--];
    }   

    bool full() const { return top == max-1; }
    bool empty() const { return top == -1; }
};

int main() {
    try{
     Stack<int> s(10);
     s.push(1);
     s.push(2);
     cout<<s.pop()<<endl;
    } catch(const Stack<int>::out_of_space& e){
     cout<< "stack out of space" <<endl;
    } catch(const Stack<int>::empty_stack & e){
     cout<< "stack is empty" <<endl;
    }
    return 0;
}

To actually use e.what() you would have to implement it yourself. Or you could inherit std::exception, overload it and just catch const std::exception&.

How do functions inform user that it throws exception based on function prototype?

Unlike some languages which indicate in the function signature that it "throws", C++ has no such mechanism. This is something you must establish in the documentation or comments near the function definition.

---

Related Topics