2

I got the following code:

set<Object*>::iterator it;
try
    {
        for (it = SetOfObjects->begin(); it != SetOfObjects->end(); ++it)
        {
            //some actions, not applicable to the question
        }
    }
    catch(...)
    {
        this->m_error_raiser->error_Name = "Station isn`t connected to Object! Use connectToObject method or list of forecast objects is empty";
        this->m_error_raiser->error_Number = 101;
        //throw (this->m_error_raiser);
    }

When instance of SetOfObjects is not created and I am trying to iterate through that set I got expected run- time error.

So I decided to handle that error and give info about it to the user by means of try catch.

My question: although I catch all exceptions thus they are considered handled, my program still terminates during run -time which contradicts to it`s behavior which I expect from it: it should continue to work because all generated exceptions were handled. What is wrong here?

spin_eight
  • 3,925
  • 10
  • 39
  • 61
  • What error are you getting? If it just terminates, it probably has nothing to do with exceptions. The code that you marked as "not applicable" seems to be the cause of the real problem. – SingerOfTheFall Aug 14 '12 at 10:25
  • 4
    If `SetOfObjects` is null or an uninitialised pointer then behaviour is undefined. – hmjd Aug 14 '12 at 10:27
  • I get unhandled exceptions. N/a code really not applicable (I have commented it out and nothing has changed) – spin_eight Aug 14 '12 at 10:27
  • 4
    If your `SetOfObjects` is a bad pointer, you are most likely getting a segfault. Just check if the pointer is valid in an `if` block. – SingerOfTheFall Aug 14 '12 at 10:28
  • @spin_eight I'd like to help but need more details. Try debugging with gbd, MSVC++, etc. Also might try to get a core dump, on linux, before executing type `ulimit -c unlimited`. Then load the core dump with `gdb `. Thank you – MartyE Aug 14 '12 at 10:38
  • @spin_eight Also, you're probably interested in adding signal handlers to catch any potential SEGFAULTS etc. Just be cautious because once in that state, you're program is *supposed* to exit, but can do so cleanly. – MartyE Aug 14 '12 at 21:43

2 Answers2

3

If object is pointer and it's not initialized, usage of such object is undefined behaviour. You can't handle usage of such pointer by exception handling (by standard). Only initialize to 0 by default and verify that pointer is not null before usage.

ForEveR
  • 55,233
  • 2
  • 119
  • 133
  • THe caveat to this - which causes much confusion to developers who have only ever using Windows - is that some (all?) versions of the C++ runtime in Windows *do* actually catch low level exceptions and generate C++ exceptions from them. You certainly shouldn't expect this to work portably! – marko Aug 14 '12 at 10:34
  • 1
    http://stackoverflow.com/questions/1823721/how-to-catch-the-null-pointer-exception – Gir Aug 14 '12 at 10:37
  • Thank you, I have read recently C++ by B.Straustroup the whole section devoted to exceptions, but I haven`t founded where anything about undefined behaviour, likely I have read it unattentivly, need to read. Previously i thought when seg fault appears it also accompined by exception. – spin_eight Aug 14 '12 at 10:47
2

In Windows environment you technically can catch low-level exceptions like this (dereferencing null/uninitialized pointer) - SEH exceptions. This is done by using Microsoft-specific __try() and __except() statements.

This may be useful, if you have an external not-so-well-written library, which crashes (follows null pointer, etc..) instead of reporting error i.e. when file is not found.

But, as already mentioned in comments, using this in your code is not portable. And they are not interoperable with C++ exceptions. So even if you decide to use them you'll end up with spagetti of 2 exception handling mechanisms... A bad design probably)

However, if youe code relies on exception-handling for error-reporting, you can always make a null check and throw a custom exception on failure: if(pointer==NULL) throw something;

Steed
  • 1,292
  • 1
  • 14
  • 33
  • Thanks. I have already solved my situation by default initialization of pointer with zero value, checking if value was changed and throwing my exception, actually I did the same as you propose. I shall read about __try, __except although they can influence program portability, so thanks for info – spin_eight Aug 14 '12 at 12:00