1

I'm trying to handle exceptions in a dialog so that if any exception occurs, the dialog will be closed and the application will not crash. As you can see, I use a simple try-catch block: 

IDialogView dialog = null;
try
{
    if (_dialogViewModel == null)
    {
        dialog = ViewFactory.SomeDialog();
        _dialogViewModel = new DialogViewModel(dialog);
        _dialogViewModel.LoadData();
    }
    _dialogViewModel.ShowDialog();
}
catch (Exception ex)
{
    if (dialog != null)
        dialog.Close();
    _dialogViewModel = null;
    MessageBox.Show("Sorry, there was an error in the dialog.", "Error",
                    MessageBoxButton.OK, MessageBoxImage.Error);
    return;
}

The problem happens when an error occurs in button's CanExecute() event handler. Error is successfully caught, but when I show the MessageBox to the user, CanExecute() executes again, and so the error happens again. In the end it results in application crash.

I've googled some info, and it were said to make sure that there is no exceptions in CanExecute() event handler. But something like this can happen somewhere else, and that's why I want to simply catch ALL exceptions in the dialog entry point without working with every method.

So, my question is: how to destroy the dialog so that after exception catch it won't show again anymore? Close() didn't work, because before closing it still calls CanExecute().

STiLeTT
  • 1,023
  • 10
  • 23
  • What is the error that occurs in `CanExecute`? Perhaps that should be fixed instead? – Fredrik Mörk Aug 09 '12 at 08:40
  • You could try disabling events on the button, i.e. remove the Button.Click() event handler. – Steztric Aug 09 '12 at 08:40
  • Yes, I have read suggests to fix the error instead or remove handler. But with this way every error can be fixed or avoided by it's own way, but the problem is that error has to be found first. Error will be fixed, but I want my application not to crash next time some missed exception occurs. – STiLeTT Aug 09 '12 at 08:43
  • P.S. The past tense of catch is caught – Steztric Aug 09 '12 at 08:49
  • Out of interest... the code you've posted isn't *in* the CanExecute method, is it? – Dan Puzey Aug 09 '12 at 08:54
  • @DanPuzey No, `CanExecute` event handler is in `_dialogViewModel`. – STiLeTT Aug 09 '12 at 08:59

1 Answers1

1

As you found when you googled, you should make sure that a CanExecute handler is a) lightweight and b) never throws an exception. You are running into the main reason for this: a CanExecute will be run repeatedly, and automatically, by the framework. It will run when focus changes, on input events, when databindings change, and in response to a number of other reasons that you have little to no control over.

The problem is: you do have an error, and that error is occurring repeatedly. That means you can choose between crashing, or showing the dialog repeatedly. Or, you can do something about the error.

Your answer: fix the error.

(Your handler as it stands is fine for your other errors. Leave it there. But this particular error, you need to fix right away.)

Dan Puzey
  • 33,626
  • 4
  • 73
  • 96
  • It's obvious that I have to fix the error. But is there any way to get rid of ALL errors? Because if I will take note of errors in `CanExecute`, I still can't be sure that there will not be any more situations like this. Is there any that I should know? – STiLeTT Aug 09 '12 at 08:57
  • What do you mean by "get rid of all errors?" You can *fix* errors - which is good - or you can ignore errors - which is bad - or you can allow errors to crash the app - which is the default, and is generally fine for errors you don't expect to see (like, say, "out of memory"). Every error you blindly ignore makes your application more unstable. – Dan Puzey Aug 09 '12 at 09:04
  • I mean all errors inside the dialog, like this one, so that only the dialog will crash, not entire application. Errors will not be blindly ignored, they'll be fixed after that, because we are getting error logs. – STiLeTT Aug 09 '12 at 09:08
  • Well, the handler you have *will* catch all errors inside the dialog; there's not much else you could do to meet that requirement. – Dan Puzey Aug 09 '12 at 09:18