 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / December 2007Exception Handling in 2.0
In .NET 2.0 any thread exception breaks the application, as opposed to 1.x where it would not. Althoguh this is a good feature in picking up potential problems and having cleaner code, what if I didn't want that to happen? I am working on a large project, which has a number of applets written in 1.0, all those applets plugin to a main exe also written in 1.0. We are thinking of moving the exe to 2.0, but the number of applets using this exe is quite large and we cannot debug each and every one of them, so this feature is kind of a problem in my case. any one run through a problem like this? anyoen who is not happy with the exception handling mechanism? > In .NET 2.0 any thread exception breaks the application, as opposed to > 1.x where it would not. Althoguh this is a good feature in picking up [quoted text clipped - 7 lines] > any one run through a problem like this? anyoen who is not happy with > the exception handling mechanism? From MSDN: <quote> As a temporary compatibility measure, administrators can place a compatibility flag in the <runtime> section of the application configuration file. This causes the common language runtime to revert to the behavior of versions 1.0 and 1.1. <legacyUnhandledExceptionPolicy enabled="1"/> </quote> Does that help?  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk > > In .NET 2.0 any thread exception breaks the application, as opposed to > > 1.x where it would not. Althoguh this is a good feature in picking up [quoted text clipped - 25 lines] > Jon Skeet - <sk...@pobox.com>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet > World class .NET training in the UK:http://iterativetraining.co.uk Thanks, I can actually use that, I was thinking if I wrap the entire line Application.run in a try catch, that might solve it too, no? > Thanks, I can actually use that, > I was thinking if I wrap the entire line Application.run in a try > catch, that might solve it too, no? No, because it won't do anything with exceptions thrown on different threads. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk > > Thanks, I can actually use that, > > I was thinking if I wrap the entire line Application.run in a try [quoted text clipped - 6 lines] > Jon Skeet - <sk...@pobox.com>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet > World class .NET training in the UK:http://iterativetraining.co.uk But I thought that once other threads have thrown exceptions, in .NET 2.0, this will bring down the main UI thread, if I do a try and catch on it (application.run()), this will prevent it. Did I misunderstand this? > > > Thanks, I can actually use that, > > > I was thinking if I wrap the entire line Application.run in a try [quoted text clipped - 7 lines] > on it (application.run()), this will prevent it. > Did I misunderstand this? Yes, I think so - I believe that in .NET 2.0 it will bring down the whole AppDomain, not just throw an exception. In particular, even if you catch the exception in Application.Run, by that point it's torn down your UI, which isn't the behaviour you'd want, is it? SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk > > > > Thanks, I can actually use that, > > > > I was thinking if I wrap the entire line Application.run in a try [quoted text clipped - 16 lines] > Jon Skeet - <sk...@pobox.com>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet > World class .NET training in the UK:http://iterativetraining.co.uk Yes it isn't. Well this won't do it, but my questions is, after your tag recommendation, if I add that tag, it will only affect the exception handling policy, or rather unhandled exceptions, so if other applets load .NET 2.0 specific dll's they won't be affected, I assume this is the case, just asking!! > Yes it isn't. Well this won't do it, but my questions is, after your > tag recommendation, if I add that tag, it will only affect the > exception handling policy, or rather unhandled exceptions, so if other > applets load .NET 2.0 specific dll's they won't be affected, I assume > this is the case, just asking!! I'm not sure what you mean. They will still be able to load .NET 2.0 DLLs, but the unhandled exception behaviour will be as per .NET 1.1. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk > > Yes it isn't. Well this won't do it, but my questions is, after your > > tag recommendation, if I add that tag, it will only affect the [quoted text clipped - 8 lines] > Jon Skeet - <sk...@pobox.com>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet > World class .NET training in the UK:http://iterativetraining.co.uk Yes that I found out, But you know if you google that tag, a number of users are not comfortable with it, as it didn't handle all exceptions properly., ie : 1 : http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=971204&SiteID=1 2 : http://lists.ximian.com/pipermail/mono-devel-list/2007-August/024748.html and did you look at this ICLRPolicyManager method, would this be a better approach? http://msdn2.microsoft.com/en-us/library/ms164400.aspx I guess at the end, would you feel comfortable, knowing that there are over 35 applets that you don't know the internal workings of their code, but are sure they are running fine using a 1.0 exe, move all of them to the 2.0 exe? > Yes that I found out, But you know if you google that tag, a number of > users are not comfortable with it, as it didn't handle all exceptions > properly., ie : > 1 : http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=971204&SiteID=1 That's not a failure in the configuration - it's a USB failure. > 2 : http://lists.ximian.com/pipermail/mono-devel-list/2007-August/024748.html Well, that's mostly mono stuff - but I don't think it's too bad. > and did you look at this ICLRPolicyManager method, would this be a > better approach? > http://msdn2.microsoft.com/en-us/library/ms164400.aspx I believe that's for when you're hosting the CLR yourself. > I guess at the end, would you feel comfortable, knowing that there are > over 35 applets that you don't know the internal workings of their > code, but are sure they are running fine using a 1.0 exe, move all of > them to the 2.0 exe? Not necessarily. There are various other incompatibilities. I certainly wouldn't do it without testing. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk > > Yes that I found out, But you know if you google that tag, a number of > > users are not comfortable with it, as it didn't handle all exceptions [quoted text clipped - 24 lines] > Jon Skeet - <sk...@pobox.com>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet > World class .NET training in the UK:http://iterativetraining.co.uk Thanks Jon, appreciate it. I actually stumbled upon a list of published differenmces from MSDN about breaking changes in .NET 2.0 from 1.1 and 1.0: Just posting them for reference for everyone. http://msdn2.microsoft.com/en-us/netframework/aa497241.aspx Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.