2

I'm trying to realize handling Windows exceptions with the help of __try/__except block.

Problem is that the program never enters __except block - only exits incorrectly.

Workspace: OS: Windows 7 x64; Framework: Embarcadero XE5 C++ Builder; Application template type: console 64-bit application (for 32-bit works normally!)

Code:

void foo()
{
   __try
   {
     int *p = 0;
     fprintf(stderr, "before action");
     *p = 1;
   }
   __except(EXCEPTION_EXECUTE_HANDLER)
   {
    printf("in __except block\n");
    throw("");
   }
}

int _tmain(int argc, _TCHAR* argv[])
{
 try
 {
   foo();
 }
 catch(...)
 {
   printf("in catch block\n");
 }

 printf("end of main\n");
 return 0;
}

Output:

before action

then incorrect exit

In the second variant I added exception handler this way:

LONG WINAPI MyUnhandledExceptionFilter(PEXCEPTION_POINTERS p)
{
  printf("in excepiton filter\n");
  return EXCEPTION_EXECUTE_HANDLER;
}

int _tmain(int argc, _TCHAR* argv[])
{
  AddVectoredExceptionHandler(1, MyVectorExceptionFilter);
  // the same text
  // ...
}

After this I got this output:

Output:

before action
in excepiton filter

then incorrect exit

Why does not the program enters __except block? Is there a way to continue working correctly after entering exception handler?

Sas
  • 523
  • 3
  • 21

2 Answers2

2
  1. *p = 1; won't throw... what you want is "throw std::Exception()"
  2. throwing is relatively expensive See here, so try{ try{ } catch {throw} } catch{} is bad. just the one try catch is needed
  3. (opinion) stick with portable things - try catch. MS added this by the looks so that they could have finally, like java does. If you use __try __catch you'll start using these and when you have to write something on Linux you'll wonder why it's not compiling

Is there a way to continue working correctly after entering exception handler?

Depends on the exception, and what it means to your program. The only suggestion is to follow the naming - Exceptions are exceptional. It could be that reading would block, in which case you can just sit around and wait for more - or it could be that a dll couldn't be loaded and it was needed by your application - in which case no, you can't recover.

Community
  • 1
  • 1
UKMonkey
  • 6,941
  • 3
  • 21
  • 30
  • Thanks for your answer! Exceptions caused by code like mine can't be caught by standard try/catch block (please, correct me but I proved it experimentally). About aim of catching: in case of critical error I want only to post my message to user and close app correctly. But in exception handler after printf it exits incorrectly. – Sas Oct 13 '16 at 14:53
  • 1
    "Exceptions caused by code like mine can't be caught by standard try/catch block " - see my point (1). Regarding your other part, we don't know what MyVectorExceptionFilter is; is there a typo in the question? – UKMonkey Oct 13 '16 at 15:02
  • 1
    I would suggest you examine https://msdn.microsoft.com/en-us/library/windows/desktop/ms681411(v=vs.85).aspx a little more closely – UKMonkey Oct 13 '16 at 15:04
2

You must be consistent. You can use the C++ try and catch to catch C++ exceptions, or you can use the Microsoft Structured Exception Handling to catch low level errors with __try, __except and eventually __finally.

In your example, you never enter the exception handler because the guarded block was incorrectly introduced with the C++ keyword try.

Just replacing the offending try with __try allows the exception handler to be correctly calles.

Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252
  • Thanks for answer! I've already tried replacing `try` with `__try` - feature remains. Question is corrected. – Sas Oct 14 '16 at 06:34
  • @Sas: I can no longer reproduce. The code currently in the question gives correctly `before actionin __except block in catch block end of main` in my old VS2008 32 bits (I use `#include #include #include ` as headers) both in UNICODE and MBCS mode. The only weird thing is that you throw a C string which could cause problem. What happens if you throw an int or a C++ string? – Serge Ballesta Oct 14 '16 at 08:10