Long-lasting objects that throw exceptions

I'm pretty new to exceptions, so please bear with me...

I have a few objects that are supposed to last the lifetime of the program and are set up so they commonly throw exceptions on construction. I hoped I'd be able to just wrap the object declarations (in main()) with a try/catch block and then use them further down the program without hassle. Then I realised the try scope is limited to that try block.

I gather that when an exception is thrown, the os (or the program?) runs down the function stack until it finds a suitable handler, abort()ing if one doesn't exist. That makes exception run in linear time w.r.t. the number of functions between throw and catch then, right? So, surely having my entire program between the throw and catches isn't exactly efficient when these throws are expected to be common?

How do people here generally deal with it? Is the function crawling even noticeable?

Quote:

---

Originally Posted by drrngrvy

I have a few objects that are supposed to last the lifetime of the program and are set up so they commonly throw exceptions on construction.

---

Sorry, I hit this red flag and couldn't move on. Exceptions are meant to be exceptional, not common. What are you using these exceptions for?

Ok, let me put it this way: the 'exceptions' are definitely errors, but since this is a web-based app, they're likely to be common. Stuff like 'wrong password', 'site not found', that kind of crap. My mistake, sorry about that.

> Stuff like 'wrong password', 'site not found', that kind of crap
Exceptions are for stuff like "divide by zero", "out of memory", that kind of crap.

Why should an application bomb out because of user finger trouble and you missing handling an exception?

If a constructor of an object throws an exception, it is not constructed. Member and base destructors of the object are called. If it was allocated with new, the memory is released again. You cannot use an object if its constructor throws an exception.

As for the efficiency, this is about exceptions. Efficiency doesn't matter in case of an exception. Besides, look at the difference between having the entire program inside and outside the try...catch.
If inside, the stack is unwound (which might take long, but does it matter?), the exception is handled, and the program continues after the handler, whatever it does there.
If outside, the program simply aborts.

Your entire exception handling model sounds very flawed.

Quote:

---

the 'exceptions' are definitely errors, but since this is a web-based app, they're likely to be common. Stuff like 'wrong password', 'site not found', that kind of crap. My mistake, sorry about that.

---

I'm not an expert, but from what I've read*, exceptions are for really unexpected errors... errors that you can't fully recover from, or that you don't know what to do when they happen.

I don't have any examples... maybe if you can't read or write anything to/from the disk drive... something like that.

* Thinknig In C++ Vol II has a full chapter on exceptions (chapter 1).

Quote:

---

Originally Posted by DougDbug

I'm not an expert, but from what I've read*, exceptions are for really unexpected errors... errors that you can't fully recover from, or that you don't know what to do when they happen.

---

I disagree with that. If you can't recover from an error, you might as well call abort() immediately.

The nice thing about exceptions is that you can recover from an error on a higher level than the current one.

Take, for example, a config file parser. If you have a GUI tool for editing configuration, or perhaps a separate configuration validator, it would definitely qualify as exceptional that the config file contains a syntax or semantic error. The parser itself, however, cannot recover, so it throws an exception.
A higher level in the application might recover by writing an error message and exiting, or perhaps loading default values and continuing.

Thanks for the advice guys. Like I said, I'm just starting with exceptions so I need this sort of criticism.

I'm going to work on it a bit more...