Uwe Keim

Cool. Already thought I forgot everything I learned from Bjarne's books

So these "checked exceptions" and your decision to avoid them is a good thing, I guess. But this would not make my original suggestion unusable, if I'm understanding correctly...

I do like exceptions, correct So in general I do like the exception model in the Framework very much.

In detail, I have problems to get the call stack information of the original thrown exception when installing a global exception handler in a C# application by implementing an UnhandledExceptionEventHandler and a ThreadExceptionEventHandler. Never been able to get this working correctly. Probably it is my fault, but since you are already asking, the Framework could help me more on this issue to avoid the mistakes I'm now making

Similar things apply when centrally catching exceptions in ASP.NET applications. But I'm trying to advance and improve!

Thanks for your feedback!
Uwe

So maybe I misunderstand: To me the term "checked exceptions" refer to declaring at the definition of a function which exceptions it throws so that the caller knows which exceptions to expect?!?

Or am I wrong?

Once I read about an exprimental feature in Java that enables code that CATCHES an exception to be able to tell the original code that has THROWN the exception to continue to execute.

This would be useful if the catcher can handle and fix/resolve the cause of the exception and then "reverse throw" the exception back where it was thrown and continue as if the exception never had happened.

Such a feature would be handy in C# as well, I guess