Are Exceptions effective?

Hi all,
I have just learned a lot about "Exceptions" (from Bruce Eckel's book, by the way). But I have read that I should not use them very often because they are very difficult to processing, thus little effective.
And now, I am confused. It is so nice and clear to use Exceptions in the code BUT they are "time-consuming".
So should I use them? Or should I use them everywhere, or somewhere, or should I try to avoid them?

Thanks.

I am glad you asked because I wanted to know that too. Sorry no answer from me.

Quote:

---

I have just learned a lot about "Exceptions" (from Bruce Eckel's book, by the way).

---

O_o

Quote:

---

Bruce Eckel

---

So... not much at all then...

Quote:

---

But I have read that I should not use them very often because they are very difficult to processing, thus little effective.

---

If you need an exception mechanism, then a compiler will likely do a better job then you ever could, and if you can do a better job, you should build a better compiler. You shouldn't use exceptions as part of controlling the flow of a program, but if any particular source benefits from what exceptions provide then you should definitely use exceptions. C++ exceptions are extremely effective at what they do, but they are not "return values".

Quote:

---

It is so nice and clear to use Exceptions in the code BUT they are "time-consuming".

---

From a mechanical perspective, they are only expensive when raised. (In practice this depends on the compiler, some compilers are simply better than others.)

Quote:

---

So should I use them?

---

Yes.

Quote:

---

Or should I use them everywhere, or somewhere, or should I try to avoid them?

---

No. Yes. No.

*shrug*

The best thing to do: contrive examples and write test cases where some employ exceptions and some do not. And of course, you can always ask for help with specific cases.

Soma

Short answer: It depends. Long answer, that is what they were invented for. They sort of break the way a program flows a bit. Because of this, they typically carry a bit more overhead than using status returns or something similar. Use them when you find they are most effective. Just don't get overly lazy and use them exclusively. They do exist for a reason. At the very least, they can be used during development and removed later. I typically do not write code in this fashion but its another issue of preference. Its equivilent to leaving ASSERT() in a production build.

Quote:

---

At the very least, they can be used during development and removed later. I typically do not write code in this fashion but its another issue of preference. Its equivilent to leaving ASSERT() in a production build.

---

There is a thin line between assertions and exceptions of the std::logic_error variety, and so for such exceptions I agree, since at least in theory these exceptions can be avoided. Exceptions of the std::runtime_error variety, on the other hand, are rather different from assertions since the exceptional course of events might well be unavoidable due to external factors.

I use MFC for many of my systems, which throws a lot of exceptions.
(I use the right 'tool' for the job at hand, irregardless of its reputation.)

I catch exceptions in most methods. In many cases the exception is due to bad data captured from a device. Catching the exception at least gives my app the chance to recover.

I write exceptions to a log, always including the class::method. This allows easier investigation of issues.

I rarely process any exceptions, except timeouts (as I may want to attempt the operation again with extended TO).

Many of my apps (asset protection systems) run in remote/unaccessable/harsh locations and 24/7 , so this aids in locating problem areas in the code (when exposed to real world conditions/data).