Exception Handling in 2.0

  • Thread starter Thread starter kalamantina
  • Start date Start date
K

kalamantina

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?
 
kalamantina said:
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?
Click to expand...

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?
 
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?
Click to expand...

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?
 
kalamantina said:
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?
Click to expand...

No, because it won't do anything with exceptions thrown on different
threads.
 
No, because it won't do anything with exceptions thrown on different
threads.
Click to expand...

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?
 
kalamantina said:
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?
Click to expand...

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?
 
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?
Click to expand...

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!!
 
kalamantina said:
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!!
Click to expand...

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.
 
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.
Click to expand...

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?
 
kalamantina said:
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
Click to expand...

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
Click to expand...

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
Click to expand...

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?
Click to expand...

Not necessarily. There are various other incompatibilities. I certainly
wouldn't do it without testing.
 
That's not a failure in the configuration - it's a USB failure.


Well, that's mostly mono stuff - but I don't think it's too bad.


I believe that's for when you're hosting the CLR yourself.


Not necessarily. There are various other incompatibilities. I certainly
wouldn't do it without testing.
Click to expand...

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
 
Back
Top