Usually the recommendation is to use Application.DispatcherUnhandledException Event
:
public App() :base() {
this.Dispatcher.UnhandledException += OnDispatcherUnhandledException;
}
public partial class App : Application {
void OnDispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e) {
// Faz o que quiser aqui.
e.Handled = true;
}
}
Another way that can be used if you want to do one last action when you are already disassembling WPF:
[System.STAThreadAttribute()]
public static void Main() {
WpfApplication1.App app = new WpfApplication1.App();
app.InitializeComponent();
try {
app.Run();
} catch (Exception ex) { //aqui é um bom local para por esta captura geral
//faz algo aqui
}
I put in the Github for future reference.
If you have a method onStartup()
in the class derived from Application
, can be a good place to put something too. It depends on how it was built.
You really shouldn’t spread the word try-cath
for every application. But there is place you need. This is the last measure, is when everything failed, when there was no specific way to solve it. And many errors are just like that. But don’t think you did it, you don’t have to worry about manipulating exceptions in a localized way anymore. Then it would be radicalism contrary to what the people usually do.
What you can even do is create a library of common actions that must be executed when an exception occurs, then call these actions within the catch
suitable. People tend to forget that "anything" in the code that will run more than once should be part of a library, should be generalized, either to eliminate repetition, or to stay longer DRY.
But the catch of the exception should be more localized even. The exception should be caught at the right time, neither before nor after the best time.
The try-catch
is a structure that controls the flow of the application, so it cannot be placed anywhere. And it’s even more complicated than other structures because it can produce global side effects. It takes a lot of care with its use.
Of course you do not need to put everywhere, this is the common mistake. And almost always the exceptions will not be thrown in the part of the WPF itself.
If you are in doubt about the correct use, you will have to ask specific questions when using in each dubious situations, until you get used.
Thank you worked perfectly. I used the first example. To display the error message to the user I can use e.Exception.Message.Tostring(); and to write to the database I can use e.Exception.Stacktrace.Tostring() and e.Exception.Message.Tostring();?
– Mauricio Ferraz