Thank you very much! Especially
Alan N wrote:
...but I thought your post was looking lonely! ...
shows a noble character, and i'm happy to see, such magnanimity still exists in the real world :) . Finally i found an answer, and a reasonable reason to call Action<whatever>.EndInvoke(): Exceptions of the sideThread are saved to the calling thread (May be you knew that already, to me it's new). In Designmode there is no difference - the Debugger stops where the exception is thrown. But in Release-mode it's important, and very dangerous, because a lost exception leaves the program running in an instable State!
using System.Windows.Forms;
using System;
using System.Threading;
namespace AsyncWorkerCs {
public partial class frmMain : Form {
\[STAThread\]
static void Main() {
Application.EnableVisualStyles();
Application.Run(new frmMain());
}
public frmMain() {
InitializeComponent();
btCreateError.Click += btCreateError\_Click;
}
void btCreateError\_Click(object sender, EventArgs e) {
var createError = new Action(CreateError);
// in Release-mode this will crash the app (recommended behavior if an unhandled exception occurs).
//createError.BeginInvoke(createError.EndInvoke, null);
// in Release-mode this will cause no Exception, but leave the app running in an undefined state!
createError.BeginInvoke(null, null);
}
void CreateError() {
Thread.Sleep(500);
throw new Exception("CreateError()!"); // in Debug-mode IDE always will stop here
}
}
}
Hmm, now i've found a reason to call Action.EndInvoke, it's one more reason to deprecate the Backgroundworker-class, isn't it? a very strong reason to deprecate it, since the dangerous behavior does not occur in Debug-mode. So it causes its surprises really late. regards
