The whole component (which is a stand alone service) crashes because of some unknown exception. After Ive started to investigating the problem I discover that the exception is an AbandonedMutexException. Since Im quite new with .NET/C#, I have no clue what this means. MSDN informs me that it means "In previous versions, the WaitOne method returns true when a mutex is abandoned. An abandoned mutex indicates a serious coding error. The exception contains information useful for debugging.". The exception is new for .NET 2.0 and is there to "help" developer.
So, now we have a service/component that works fine in the old .NET 1.1 but can potentially crash in the new environement. Even if there is a "serious" coding error in the product, it has worked as it should for at least 2 years. But now MS wants to "help" their developers to write better code, but the problem is that they did not tell the developers that something happened. This would not happen if C# had checked exceptions, because this would have been caught when compiling with .NET 2.0. Now it was caught by "misstake" and could have been shipped if I didn't do something wrong to provoke the error. Sure MS will help the people who is developing new software, but they just made it harder to maintain software.
I havent still made up my mind about Checked vs Unchecked exceptions. But I believe that if C# had Checked exception this problem would have been caught when moving to .NET 2.0 and not 6 months later. It was impossible to test every part of this huge system when the move was made and therefore it passed. It has come to my understanding that coding with Unchecked exceptions means catching unnamed exceptions here and there. In one component I saw 120 catch statements, 12 was for named exceptions and the rest was just "catch(Exception)". That is not handling an exception, that is hiding an exception from reaching the user or crashing the application. For me catching unnamed exceptions all over the place is bad code.
Aftermath
Sure, I found the problem. It was not a big one, and is definetly not a "serious" code error that could have horrendous effects. Yes, it was a coding problem. The problem is that it could have reached the customer, and in my eyes MS played a major part in provoking the error that could have reached the customer. Bad PR for the company, no PR change for MS. tsk, tsk, tsk.
