VS 2017 Application Exit after error-VBForums
Results 1 to 9 of 9

Thread: Application Exit after error

  1. #1

    Thread Starter
    New Member
    Join Date
    Jan 2018
    Posts
    9

    Question Application Exit after error

    Let's assume that deep down in this app an error occurs and is caught by a Try block. What is the best way for the app to end?
    By 'best' I mean with regard to closing all forms, releasing all resources and being clear to follow in code what is happening etc.

    Does anyone have an innovative|neat|cool|beautiful way of doing this?

  2. #2
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,579

    Re: Application Exit after error

    If the exception handler that you mention can't do anything useful, then what is it there for? Normally, you would want to catch an exception as close to where it is thrown as is reasonably possible, but that's just because you'd be able to address the issue at that point. In this case, you are really saying that such an error handler can't address the issue at all, and the only alternative is to abandon the entire program. Therefore, why bother catching the exception that deep? You could have an exception handler much higher, perhaps even at the application level, and do the cleanup there. After all, an exception handler buried deep in the code is likely not to know about all the parts of the application, so that particular code block is unlikely to be able to do much cleanup. The exception handler could call a method that did a bunch of cleanup, but that could be problematic if you want to try to cleanup whatever object the exception handler is found in. Alternatively, you could re-throw exceptions that you can't handle locally, and let them be caught at an outer level. That seems nearly the same as just not catching the exception, though, except that you have the opportunity to pass it back up a chain, doing a bit of cleanup at each step.
    My usual boring signature: Nothing

  3. #3

    Thread Starter
    New Member
    Join Date
    Jan 2018
    Posts
    9

    Re: Application Exit after error

    Shaggy, thanks for your reply although I'm unsure if it addresses my question.
    You ask "If the exception handler that you mention can't do anything useful, then what is it there for?", well my intention was to at least put out some message describing exactly where the error happened and why. Is that not a useful thing to do? The current app is used by hundreds, maybe thousands, of unskilled, untrained, users world-wide, they experience and perhaps cause many unusual issues and the more information I can get the easier they are to fix.
    I understand about where exceptions can be caught, my question stated "What is the best way for the app to end?", there was, I agree, an implied "the handler is unable to fix the issue", for example a required file is not available because the user moved or deleted a folder and what I'm asking is "what is the best way for the app to bring things to a neat end".
    Thinking back to good-old VB6 days, there was the infamous "End" statement which many developers used but could cause memory leaks. I'm trying to avoid similar issues by finding the preferred way to exit from vb.net.

  4. #4
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,579

    Re: Application Exit after error

    Sure, that's a useful thing to do. Additionally (and possibly alternatively) you could log the error to a file such that others could review it later. In fact, you could log the entire call stack. However, having done that, you could then re-throw the exception (or a slightly different one) and catch it at a higher level. If the only viable solution is log the problem and quit, then this is a pretty reasonable thing to do. You could throw a custom exception from the exception handler after doing any logging/messageboxes that you wanted. The custom exception could then be caught at the application level, which would have sufficient scope to do the cleanup. However, that cleanup likely doesn't have a very generic solution. If somebody knows of a safe, generic way to clean up EVERY type of program, I'd be interested in hearing of it.

    If you have threads, you'd have to end them, and that alone can be a real problem, depending on the thread. You may have to let them run to completion, or you may be able to safely abort them (a brutal solution which is often as bad as End), or you may have a cancelation mechanism implemented. For other existing objects, you'd have to do your own cleanup. You can get to running forms and close or dispose each one, but whether that cleans up any resources they have depends on whether they have any, and if they do, it depends on them cleaning them up in their Dispose implementation. For other objects, if they need to dispose of things, they should implement IDisposable and do the cleanup in there, at which point you can call their Dispose method in your cleanup.

    So, lacking any generic method, it comes down to whether the objects (forms and others) are written such that they clean themselves up on Dispose, and whether you are using threads and if so, whether they can be canceled. If all is done well, then you can just go through any global objects and displayed forms, disposing of each of them. Quite often, you don't even need to. Most forms don't hold any resources. Most custom classes neither implement IDisposable, nor need to. All of those things can be simply thrown away, in which case even End could work. It all comes down to the program, though.

    The End statement still exists, and you can add Application.Exit (or something like that, I've never actually used it explicitly). It has the problems you note.
    My usual boring signature: Nothing

  5. #5
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,462

    Re: Application Exit after error

    This is a tough question and the answer can only be given in a high-level manner.

    Ideally, you use a Try/Catch because there are errors you KNOW you can fix. The Catch is there to do the "fix" part. Sometimes you "fix" a problem by merely telling the user you couldn't do what you said you'd do.

    Sometimes, you don't have away to "fix" the error. Or, it's an error outside what you know you can "fix" so you aren't sure if you can. The original design of .NET Exceptions suggested you should let those go uncaught. This causes the application to crash with little ceremony, so it's not a very good design.

    Doing something with an unknown exception can be difficult. You can log that it was thrown, but what do you do so your code can communicate back up the call chain that it failed? There are a lot of choices, but that can really only go up the call stack. If you have other parts of the application that aren't part of that call stack, they won't know something went wrong and that they need to close.

    Things like End or Application.Exit() can be messy, but in certain error cases there's no clean way to respond.

    Most of my "big" apps these days have some central type that everything depends on. The pattern is "Event Aggregator" but has many names. Anything in the program can post a "fatal error" message, and that'll instruct all the other pieces of the program to calmly try to clean themselves up and close.

    That's more or less the best approach: if you want to die gracefully when an error happens, you need a mechanism to communicate application-wide that such a thing has happened.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  6. #6

    Thread Starter
    New Member
    Join Date
    Jan 2018
    Posts
    9

    Re: Application Exit after error

    That's an interesting thought Sitten which I will certainly give some thought to.
    One idea that occurred to me was to throw a user defined error in the catch block (or just after it if inside isn't allowed) which can be tested for in other blocks and passed up the tree. This sounds similar to your "Event Aggregator" so I may look further into that also.
    To be honest I was kind of hoping that MS$$ had learned by their mistakes in VB6 and implemented error handling properly, I agree that Try/Catch is an improvement but it still seems lacking.

  7. #7
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,462

    Re: Application Exit after error

    I haven't really seen an error handling mechanism that I like. Try/Catch has its issues but you have to learn to design around it. If you think you've found a better one than exception handling or error codes, not only are you wrong odds are someone's already tried it and found the flaws

    The "problem" is exceptions work "vertically" in the application. Only the things that called code that resulted in the exception can have a shot at responding to the exception. There's no way to throw exceptions "sideways" such that everything else in the application can see it. This isn't unique to Exceptions, all error handling mechanisms to date have this issue because it would be very scary if an error in one place could generally interrupt code in all other places.

    The problem is you want this "sideways" behavior if the exception is one worth tearing the application down over. To get there, you have to implement something yourself.

    That's why Event Aggregator works. It's a thing with an event any interested application object can subscribe to. When the exception happens, it goes "vertical" until it's caught. Then the thing that catches it tells the Event Aggregator it's time to die.

    Event Aggregator could be as simple as a Module, I don't really like static state but it's a good way to start thinking about crossing horizontal slices.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  8. #8

    Thread Starter
    New Member
    Join Date
    Jan 2018
    Posts
    9

    Re: Application Exit after error

    Hi Sitten, I'm unsure why you are suggesting I'm trying/needing to go 'sideways'. I don't really care which direction it goes in, any which way is fine by me. All I want is an easily documented, globally acceptable, reliable way to close an application after an error happens that will unfailingly close all forms and do a dispose of all allocated resources.

  9. #9
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    31,579

    Re: Application Exit after error

    That can't really exist. You can do something like that if you aren't threading, but a thread can be so unrelated to the UI thread that it can keep running even after the application exits. However, if you exclude that slightly peculiar case, I'll be interested to see what people suggest.

    I'm currently working on a modular system. The plugins know nothing about the main program or each other. As each one is created, it gets an instance of a certain object. All communication goes through that one object, and what goes through that object is the ONLY interaction any one plugin has with the main program or any other part of the program. Therefore, I was interested to read what Sitten wrote, as he roughly described how errors work in that system. Any exception caught by one of the modules raises an event on the common module. Most of them ignore that event. However, I then wrote a plugin that handles those events and logs the information that comes with them. Thus I have a plugin that is logging the information about exceptions even though it is unaware of the very existence of the module that threw the exception.

    Even so, it doesn't do what you are talking about. The logging plugin does just that, along with providing a single source of feedback/error organizing for the larger program. The main program could handle an exception, or an event about an exception, and decide to shut down. It could decide to shut down for other reasons, too, such as the user opting to exit. In that case, it raises an event that all the modules SHOULD be handling to clean themselves up, as needed. So I have an event that any module should handle to do what you are talking about, but it is still up to the modules to handle the event and take their own action.

    I think you might see that the solutions depend on the situation, and there may be no generally agreed upon pattern.
    My usual boring signature: Nothing

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width