Ok I think I have it: http://msdn.microsoft.com/en-us/library/ms228965.aspx#ChangeFromPreviousVersions
tells us that since .net 2.0 the runtime does not swallow threadpool exceptions. So that means that the mono implementation is wrong. On Wed, Jul 21, 2010 at 9:51 PM, Daniel Hughes <[email protected]> wrote: > upon further reading this appears to be the correct behavior. Although > it does not seem to be what is happening in .net I will need to do > more investigation it seems. > > On Wed, Jul 21, 2010 at 9:16 PM, Daniel Hughes <[email protected]> wrote: >> In trying to port our application to run on mono I have discovered >> that mono is silently swallowing exceptions. This is a really big >> deal, we expect these exceptions to bubble up and kill the >> application. >> >> There is not even any indication that an exception has occurred it is just >> lost. >> >> public static void Main (string[] args) >> { >> Action action = () => >> { >> throw new Exception("this should Kill the >> process but doesn't"); >> }; >> >> ThreadPool.QueueUserWorkItem(_ => action()); >> while(true) >> { >> Thread.Sleep(1000); >> Console.WriteLine("wrongly still running"); >> } >> } >> >> The implications of this could be catastrophic. Imagine some code >> which performs a check, finds bad data and throws an exception. >> However mono swallows that exception so instead of the program closing >> it carries on running and uses the bad data. This results in sensitive >> data being lost. Or in our case a radio being bricked. >> >> Can someone explain why mono is doing this and if their is some >> setting / environment variable I can change to make unhandled >> threadpool exceptions terminate the process as is expected. >> > _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
