tags:

views:

187

answers:

7

I'm using the GLUTesselator and every once in a while EndContour() fails so I did this:

         try
        {
            PolygonTesselator.End_Contour();
        }
        catch (int e)
        {
            renderShape = false;
            return;
        }

Why would it still crash, it should perform the catch code right? How could I fix this?

Thanks

+1  A: 

Why would it still crash, it should perform the catch code right? How could I fix this?

Most likely because you are not actually catching what is being thrown. Are you sure that PolygonTesselator.End_Contour(); throws an int?

wilx
How can I tell what it throws?
Milo
Couldn'y find it yet I'm sure you can - check GLU's documentation. End_Contour() must be mentioned somewhere! And in that place look for possible throw. If that doesn't exist maybe you should reconsider using another library.
Poni
+10  A: 

Does PolygonTesselator.End_Contour(); crash or throws it an exception?

Note that a real "crash" (segfault, illegal instruction etc.) does not throw an exception in the sense of C++.

In these cases, the CPU triggers an interrupt - this is also sometimes called exception, but has nothing to do with an C++ exception.

In C++ you are running on a real CPU - and not in a virtual machine like in Java where every memory violation results in language execption like NullPointerException or ArrayOutOfBoundsException.

In C/C++ a CPU exception / interrupt / trap is handled by the operating system and forwarded to the process as "signal". You can trap the signal but usually this does not help for crashes (SIGSEG, SIGILL, SIGFPU, etcc.).

IanH
Minor nitpick: it depends on the OS. On Windows, access violations are indeed raised as catchable C++ exceptions. One of the many reason `try{...} catch(...){}` blocks are exceptionally evil in cross-platform code. Now, the exceptions raised do not derive from `std::exception`, so if you catch on that, instead of swallowing all types, you're in a slightly better state for debugging.
Nathan Ernst
@Nathan: No, they aren't. SEH cannot be intermixed with C++ exceptions. MSVC has a setting for SEH vs C++ exceptions. It's true that you CAN set MSVC to do this. However, it's not a C++ exception.
DeadMG
@DeadMG, I just double checked my VC7.1 settings (yes, I'm stuck using a 7yr old compiler), and the only flag I see set controlling behavior is `/EHsc` - Enable C++ Exceptions. I don't see anything explicitly controlling SEH behavior. Possibly a side effect of another setting? Any idea what the flag is?
Nathan Ernst
@Nathan Ernst: VS2008 and 2010 have "Enable C++ Exceptions: Yes (/SEH)" for Structured Exception Handling. http://msdn.microsoft.com/en-us/library/1deeycx5(VS10.0).aspx
DeadMG
+2  A: 

Since all you want to do when the exception arrives is set 'renderShape' to false I'd recomment the following code:

     try
    {
        PolygonTesselator.End_Contour();
    }
    catch (...) // takes any type of exception
    {
        renderShape = false;
        return;
    }

That said of course if you really can't fix the source to the exception itself!!

Poni
This isn't accurate. In his case, the Ellipsis won't catch the SEH exception, unless he specifically defines it.
Itsik
It worth a try that's one. Secondly, as I've said in the comments - he should actually try to fix it, starting with GLU's documentation! Thirdly, if the documentation doesn't help then it's more likely that there's a flaw in his code and not the lib's, which implies a full check. Since he says that this happens "once in a while" I'd bet there's some sort of event/race-condition in the background that isn't handled properly.
Poni
Don't swallow all exceptions with catch(...), it's a hallmark of sweeping bugs under the rug. It's a sign of bad programming.
C Johnson
Correct. That's what I was trying to say when said that the OP should fix the cause to the exception, so he won't need the try/catch at all.
Poni
+1  A: 

If your program fails with the message error reading from location 0x000000000, then it is not failing because of an exception, but because of a segfault. You can use the segvcatch utility to convert segfaults into catchable exceptions. Check out their examples.

Gianni
+4  A: 

You're getting SEH exception, or Structured Exception Handling. These exceptions are thrown by Windows under an entirely different system since SEH predates C++, and can't be caught by a standard C++ catch block (MSVC does however provide SEH catching).

Alternatively, if you're on Unix, the kernel doesn't use C++ exceptions either. It uses signals. I don't pretend to understand signals, since I don't develop for Unix, but I'm very sure they're not C++ exceptions.

You've violated a hardware rule that you can't de-reference a NULL pointer. You'll get an OS-level error, by exception or signal. You can't catch these things in a C++ catch block just like that.

Edit: If you're using MSVC on Windows and have a recent compiler, you CAN enable /EHa, which allows you to catch Structured Exceptions as well as C++ exceptions. I wrote this code that functions as shown:

int main() {
    std::string string = "lolcakes";
    try {
        Something s;
        int i, j;
        i = 0; j = 1;
        std::string input;
        std::cin >> input;
        if (input == "Structured")
            int x = j / i;
        else
            throw std::runtime_error("Amagad hai!");
    }
    catch(std::runtime_error& error) {
        std::cout << "Caught a C++ exception!" << std::endl;
    }
    catch(...) {
        std::cout << "Caught a structured exception!" << std::endl;
    }
    return main();
}

Structured Exceptions include Access Violations, your particular error.

DeadMG
+1  A: 

As mentioned, this is an SEH Exception.
If you are using Visual Studio, you can configure your project to catch SEH exceptions in your try/catch block.

Project Properties > C/C++ > Code Generation > Enable C++ Exceptions > Yes with SEH Exceptions

Itsik
+1  A: 

Two things :

  • If you are under VC 6 or more recent, use _try{}_except(EXCEPTION_EXECUTE_HANDLER){} instead. It will catch the SE. try/catch only catches C++ exceptions
  • I've had a hard time with GLU, so I can tell you this : if you can set the normal, SET IT. But otherwise, it's true that it's quite solid.
Calvin1602
Finally, someone actually figured it out! Thanks
Milo
what did I figured out : the SE or the normal ? What do you do to the poor GLU to make him crash ;) ?
Calvin1602
I had already set the normal but thanks. I tried MESA GLU but it crashed like the Windows one. Only the old one from OGLDDK95 never crashes and works flawlessly. I guess I'll just have a dll dependency :(
Milo