locked
Using SEH Exceptions a good recommended practice or outdated? RRS feed

  • Question

  • Using SEH Exceptions a good recommended practice or outdated?

    I want to implement exception handling in my code and only SEH catches NULL and other access violation issues at runtime as it works and catches nicely these exceptions.

    But I am not sure if SEH exceptions are still used.

    I want to use it with normal try and catch commands but I could see some examples with __try __except() commands.

    any harm in using SEH exceptions enable with try and catch commands and is it the appropriate and modern way?


    Sharing is profitable only if it happens with knowledge.

    Tuesday, January 28, 2014 6:48 AM

Answers

  • On 28/01/2014 07:48, dharan06 wrote:

    Using SEH Exceptions a good recommended practice or outdated?

    In modern portable C++, you may just want to use ordinary C++ exceptions and RAII pattern (with classes with proper destructors to do automatic cleanup).

    You may consider deriving your own exceptions from the STL standard std::exception class, or you may want consider std::runtime_error as a base for your run-time errors exceptions.

    The SEH mechanism doesn't play well with C++ and RAII; moreover, it's Windows-specific and not cross-platform, and it's designed more with C in mind.

    SEH should be used only when it is the only option, e.g. in some low-level Win32 code that does require it (for example because the involved Win32 APIs are designed in such a way to use SEH as their error handling mechanism).

    Giovanni

    • Proposed as answer by Anna Cc Thursday, January 30, 2014 7:31 AM
    • Marked as answer by Anna Cc Tuesday, February 4, 2014 2:23 AM
    Tuesday, January 28, 2014 12:04 PM
  • "I want to implement exception handling in my code and only SEH catches NULL and other access violation issues at runtime as it works and catches nicely these exceptions."

    Catching accession violation exceptions = bad idea, don't do it. An access violation exception is the result of a bug in the program. The bug needs to be fixed, not hidden with an exception handler.

    "But I am not sure if SEH exceptions are still used."

    They are but only for very particular scenarios. For example you could have a __try/__except where the handler creates a memory dump of the application and terminates the program. Another valid issue is with memory mapped files, any I/O error during reading/writing the memory mapped file is communicated back to the program via a SEH exception, if you want to handle the I/O error then you have no choice than to use __try/__except.

    "I want to use it with normal try and catch commands but I could see some examples with __try __except() commands."

    __try/__except doesn't mix well with C++, it's really a C construct.

    • Proposed as answer by Anna Cc Thursday, January 30, 2014 7:31 AM
    • Marked as answer by Anna Cc Tuesday, February 4, 2014 2:23 AM
    Tuesday, January 28, 2014 7:10 AM
  • "Modern C++" programming recommendations would be to use C++ exception handling (/EHsc) and RAII to make exception-safe code. Remember that you should not 'eat' unknown exception catch(...) should  only ever rethrow) and you should only handle exceptions you can actually recover from.

    http://msdn.microsoft.com/en-us/library/hh279678.aspx

    One of the problems with SEH is that it catches exceptions that really do mean the system is in an entirely unknown state (like access violations) and there's no safe method to recover the program.

    • Marked as answer by Anna Cc Tuesday, February 4, 2014 2:24 AM
    Friday, January 31, 2014 7:43 AM

All replies

  • "I want to implement exception handling in my code and only SEH catches NULL and other access violation issues at runtime as it works and catches nicely these exceptions."

    Catching accession violation exceptions = bad idea, don't do it. An access violation exception is the result of a bug in the program. The bug needs to be fixed, not hidden with an exception handler.

    "But I am not sure if SEH exceptions are still used."

    They are but only for very particular scenarios. For example you could have a __try/__except where the handler creates a memory dump of the application and terminates the program. Another valid issue is with memory mapped files, any I/O error during reading/writing the memory mapped file is communicated back to the program via a SEH exception, if you want to handle the I/O error then you have no choice than to use __try/__except.

    "I want to use it with normal try and catch commands but I could see some examples with __try __except() commands."

    __try/__except doesn't mix well with C++, it's really a C construct.

    • Proposed as answer by Anna Cc Thursday, January 30, 2014 7:31 AM
    • Marked as answer by Anna Cc Tuesday, February 4, 2014 2:23 AM
    Tuesday, January 28, 2014 7:10 AM
  • On 28/01/2014 07:48, dharan06 wrote:

    Using SEH Exceptions a good recommended practice or outdated?

    In modern portable C++, you may just want to use ordinary C++ exceptions and RAII pattern (with classes with proper destructors to do automatic cleanup).

    You may consider deriving your own exceptions from the STL standard std::exception class, or you may want consider std::runtime_error as a base for your run-time errors exceptions.

    The SEH mechanism doesn't play well with C++ and RAII; moreover, it's Windows-specific and not cross-platform, and it's designed more with C in mind.

    SEH should be used only when it is the only option, e.g. in some low-level Win32 code that does require it (for example because the involved Win32 APIs are designed in such a way to use SEH as their error handling mechanism).

    Giovanni

    • Proposed as answer by Anna Cc Thursday, January 30, 2014 7:31 AM
    • Marked as answer by Anna Cc Tuesday, February 4, 2014 2:23 AM
    Tuesday, January 28, 2014 12:04 PM
  • Ok..I understand that using c++ based try catch exceptions is better. But I am really not sure about why to use try catch 

    1)Why Try catch, If I can handle functions through error code. How better it is.

    2)why Try catch, if it need not be used for handling access violations.

        - I understand handling access violations is a bad idea, but definitely I want to catch if at all an unhandled access violation so as to not crash my software.

    And so now I am a bit confused on using exceptions and even if I use should I use SEH exceptions to handle access violations.


    Sharing is profitable only if it happens with knowledge.

    Friday, January 31, 2014 3:06 AM
  • "Modern C++" programming recommendations would be to use C++ exception handling (/EHsc) and RAII to make exception-safe code. Remember that you should not 'eat' unknown exception catch(...) should  only ever rethrow) and you should only handle exceptions you can actually recover from.

    http://msdn.microsoft.com/en-us/library/hh279678.aspx

    One of the problems with SEH is that it catches exceptions that really do mean the system is in an entirely unknown state (like access violations) and there's no safe method to recover the program.

    • Marked as answer by Anna Cc Tuesday, February 4, 2014 2:24 AM
    Friday, January 31, 2014 7:43 AM