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!
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