Quote:
|
Originally Posted by MBirchmeier
Non-standard: I don't know quite what you mean by this. If by non-standard you mean it makes use of an error handling module I'd disagree, passing references of your error routine classes fits well within OOP standards. I can't think of any other standards it might be breaking.
|
If I want to catch a custom exception in VB.NET (or, indeed any language that supports exceptions):
Try
SomeFunction("Foobar")
Catch ex As FoobarException
Console.WriteLine(ex.Message)
Finally
SomethingElse()
End Try
The only custom error handling part is FoobarException. Everything else is standard and instantly recognisable. With a custom error handling system, there would be no standard components. This would make the code more difficult to read for those unfamiliar with the error handling system.
Quote:
|
Originally Posted by MBirchmeier
No stack transversal: True, but raising an event can implement similar functionality, across not only the current thread, but others as well. One datasource might be updating one or more pages or controls, raising an event notifies all reliant parts what's going on, not just those on the direct stack.
|
That is one advantage, but it's an advantage that integrates easily with the current exception handling model. Just add some class variables and a few synchronization control structures to the base exception class and you're done. The only advantage I can think of to a custom exception handling scheme is that it doesn't by default halt operation of the function, but most of the time you want to halt invalid operations, so it seems a sensible default to me.
Quote:
|
Originally Posted by MBirchmeier
Lacks compile time checking: I don't see how so. Can you give an example of this?
|
Neither VB.Net nor C# have checked exceptions, so I'll have to descend into Java, which does support this:
void foo() throws FoobarException {
throw new FoobarException();
}
void bar() {
foo(); // Compile time error - FoobarException is not caught
}
As the above code demonstrates, you have to explicitly catch an exception, or pass it up to the next level. An exception cannot be left uncaught (unless it inherits from RuntimeException). This theoretically ensures that all exceptions are handled - otherwise Java refuses to compile the program.