ignoring exception - is this a problem?

If the function func() throws an exception, but we don't call the func() from try clause (to at least swallow the exception), let alone use catch clause, would that possibly show some undefined behaviors later on?

Code:

---

int main()
{
...condition is setup for func() to throw an exception...
    func();
...program goes on...
    return 0;
}

---

I was reading a c++ reference book, and it was talking about a function storing exception information into a call stack after each of a try or catch clause. Did I get that right? Then from the function below if func2() throws an exception, does that get stored in func2's call stack, or func1's call stack.

So in general, I'm confused as to how and why call stack is used to keep the exception information and what consequences I have related to this if I don't swallow/catch the exception like the example shown above.

Code:

---

int func1()
{
...
try{
    func2();
}
...
    return 0;
}

---

Quote:

---

Originally Posted by chiefmonkey

So in general, I'm confused as to how and why call stack is used to keep the exception information and what consequences I have related to this if I don't swallow/catch the exception like the example shown above.

---

I cannot answer your question about an implementation of exceptions since I have never investigated the topic, but I can tell you that in general the lack of a try/catch construct is not a problem since the exception will just propagate. However, you should not allow exceptions to propagate across module boundaries. In your example, this means that you should have a try/catch for the main function if func() might throw or propagate an exception.

Ignoring an exception is valid from a compile standpoint but not from a code standpoint. Exceptions are usually not thrown unless critical errors have occurred. So what you are asking is if it is ok to ignore a critical error. My answer would be no. If it is not a critical error then an exception should not be thrown and the error could be dealt with via return values or some other mechanism.

If you were forced to write a try block, you'd need a catch block, since the two are always paired. But how could you possibly know what to place inside the catch block if you did not know the semantics of the exception? Code can call other code. This code might throw an exception. You are not forced to handle this exception exactly because you might not know how to handle it.

So no, it's perfectly valid to not catch every exception at every point in the code (in fact, it sounds a bit strange when put that way doesn't it?)

Normally when a third party library function or DLL function can throw an exception it will be documented in the readme or the docs that come with it. And you can always catch the exception even if you do not know what it is using a catch all. It does not give you much information but it does allow you to notify the user of the app that something bad has happened and it allows you some way to gracefully shut down or handle the issue.

Catching exceptions is a simple way to diagnose and correct errors even though once you fix the issue at hand the exception may never be caught again. I know of software companies that require you to catch every exception and check every single return value. A bit annoying and overkill but it does have some worth to it. If you get into the habit of ignoring exceptions you will eventually ignore one that will cause major problems.

There is also code you can write that will give you a stack trace even in an exception in release mode. This is talked about in MS's reference about debugging inside Visual Studio. The 2003 debugger did not provide a stack trace but it was possible to get one with some assembly and C code. I'm not sure if 2005 and 2008 have more functionality in the GUI-based debugger but I seriously doubt it. The core debugger is extremely powerful but the GUI-based front-end to it that ships with MSVS is a bit gimped and does not use all the features.

Quote:

---

Originally Posted by Bubba

Catching exceptions is a simple way to diagnose and correct errors even though once you fix the issue at hand the exception may never be caught again. I know of software companies that require you to catch every exception and check every single return value. A bit annoying and overkill but it does have some worth to it. If you get into the habit of ignoring exceptions you will eventually ignore one that will cause major problems.

---

I agree that one should catch every exception and check every single return value. However, catching every exception is not the same as placing a try/catch around every block of code from which an exception might be thrown. Unless it means propagation across a module boundary, an exception should be allowed to propagate if it cannot be handled or translated appropriately at a given point.

Quote:

---

Originally Posted by laserlight

I agree that one should catch every exception and check every single return value. However, catching every exception is not the same as placing a try/catch around every block of code from which an exception might be thrown. Unless it means propagation across a module boundary, an exception should be allowed to propagate if it cannot be handled or translated appropriately at a given point.

---

Hear, hear!

Among the many gripes in my life are the programmers who insist that "must catch every exception" equates to "every function must have a try/catch block in it to catch every exception".

One of the design rationales of exceptions is that they need not be caught by code that can't do something rational to correct the triggering error condition.

Unfortunately, crossing module boundaries (eg an exception propagated from a DLL to the calling application) often causes problems for various reasons.

Quote:

---

However, catching every exception is not the same as placing a try/catch around every block of code from which an exception might be thrown. Unless it means propagation across a module boundary, an exception should be allowed to propagate if it cannot be handled or translated appropriately at a given point.

---

Agreed and well stated.