none
Exception Handling In C#, C++ RRS feed

  • Question

  • Hi there. This is just a suggestion to the Community and a request to engage with the Microsoft Development Community. Just a thought for your consideration : I think it is good practice to have an exchange handler at the top level in the main function that has a generic catch clause such as in C# catch(System.Exception e). All exceptions handled here are not handled by the code elsewhere lower down in the program so should be logged and incorporated and reacted to in a new build, and the program might not necessarily terminate. You could even put the application live and have an exception monitor to tell you of unhandled exceptions. These might not result in termination / interruption of the program depending on what they were and the new system build and release could take them into account. What do you think please ? Any thoughts / feedback very welcome.

    Many thanks and best regards, Taher Hassan

    Sunday, September 29, 2019 12:44 PM

All replies

  • I am always of the opinion that if an exception can get back to the last ditch exception handler then the application is better off terminating.

    This exception handler is never going to be able to correct any problems because any exception that gets caught by this handler is always going to be a completely unexpected exception. How are you reasonably expected to recover from an exception if you never knew that you could get it in the first place.

    There have been plenty of people who try to keep their applications going no matter what but eventually the application will have to be restarted, and by this point you are well beyond being able to figure out what the problem is.

    The best thing you can do when you get an unexpected exception is to let the program crash. If you want to try to log it in the handler then you can try, but you shouldn't try to handle the exception. This will then give you a nice crash dump at the exact location that the application threw the exception so you can see exactly what went wrong.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Sunday, September 29, 2019 2:28 PM
  • For another take on why catching and handling an unexpected exception in a top level handler is problematic I suggest you read How to turn off the exception handler that COM "helpfully" wraps around your server
    Sunday, September 29, 2019 2:36 PM
  • Hi there Darran and RLWA32, Many thanks for your good responses I appreciate and am very interested in your comments and feedback. Yes I just wanted to add a point to what I said and then answer the point made by you RLWA32. When logging the exception details you can include the exception message, the call stack, and the file and line the exception was thrown. You could also produce a flashing warning to the user on the UI if you wanted to tell them that a potentially serious error had occurred. But if in analysing the exception error output to the UI and the log it was deemed to be not serious the application could be left to run as normal and not terminate. Then the exception could be properly dealt with in later build and release. If however it was deemed to be serious the perhaps business critical application could be closed gracefully at a suitable point in time. Hope this helps.

    Many thanks and best regards, Taher Hassan

    Sunday, September 29, 2019 5:49 PM
  • This is just a suggestion to the Community and a request to engage with the Microsoft Development Community. Just a thought for your consideration :

    So this is not a question. It should be made a Discussion. Do you know how to do that?



    Sam Hobbs
    SimpleSamples.Info

    Sunday, September 29, 2019 6:24 PM
  • I see you are posting many of these posts that should be a discussion.


    Sam Hobbs
    SimpleSamples.Info

    Sunday, September 29, 2019 6:39 PM
  • How could the exception handler in the main function deem that it wasn't serious? The fact that it got to that exception handler means that the application wasn't expecting that type of exception in the first place. If it was an exception that you could deal with and was expecting, first it would be questionable calling it an exception, (the .NET framework is terrible for using exceptions for message passing in non exceptional situations), and second you would actually deal with it closer to the exception site.

    Also, you say that the by having this all encompasing exception handler would allow the application to run as normal, but that wouldn't be the case. By simply handling the exception in the main function you would take an exceptional path all the way back to the main function, destroying lots of objects in the process. Only global objects would survive this and they could very well be in a corrupt state due to the exception handling.

    The way to think about it is that by having an exception bypass all other exception handlers and get back to the last general exception handler, your application is in a corrupt state and this exception handler can do nothing to fix this. If you continue execution then your application will continue from this corrupt state.

    As an example. Suppose you are using a custom memory allocator in a C++ application and the allocation fails. This allocator throws a custom exception to indicate that something went wrong.

    The exception handler in main knows nothing about this allocator's exceptions and so it gets an exception which may not even derive from std::exception. So beyond knowing that the exception was thrown, the exception handler has no idea what the type of the exception is or what it even means. If the exception means that the memory allocator is out of memory, or it is in a corrupt state then you can't continue and you can't even know if this is the case.

    Another situation to think about is if you are in a C# applications main function and you just caught an exception. You somehow figure out that this is a FileNotFoundException. First, since you are now in an exception handler in the main function, you have no idea where this exception came from so you can't know how to deal with it. Second, the exception itself doesn't tell you how to deal with it. This could have been thrown due to you misspelling a file name, it could have been thrown due to the file being deleted or it could be missing due to filesystem corruption. How can your exception handler deal with this? How does it even know that this is serious or not?


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Sunday, September 29, 2019 6:55 PM
  • Also, logging the exception is nowhere near as good since the program is unwound up to the exception handler that catches the exception. This means that you lose all local variables.

    If one of these local variables is what unexpectedly failed then you lose the state of an object in its error state. The file and line that the exception was thrown is also not as useful since this is only where the error was detected, it is more than likely that where the error occured was before this point. So getting a memory dump with the state of all live objects is more preferable to a call stack.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Sunday, September 29, 2019 7:30 PM
  • Many thanks for your responses - I will analyse them as soon as I can. I just wanted to add that when you display the exception information on the UI Exception Monitor or log them you could also include the Date and Time the exception occurred. Thanks and regards, Taher Hassan
    Monday, September 30, 2019 11:18 AM
  • Hi Taher,

    >>I just wanted to add that when you display the exception information on the UI Exception Monitor or log them you could also include the Date and Time the exception occurred.

    You can customer code to capture the data and time as a workaround:

    https://stackoverflow.com/questions/15291328/does-system-exception-have-a-built-in-thrown-timestamp

    In addition, current VS may has no certain features or functions you want to get, so we just provide our suggestions or workaround for those issues. If you really have some suggestions or ideas, you could submit the feature request to the product team directly with the VS IDE.

    https://docs.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2019

    Best Regards,

    Jack


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, October 2, 2019 5:55 AM
    Moderator