Quote:
|
Originally Posted by Arevos
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
|
A trivial point, .NET doesn't support Try/Catch/Finally clauses, only Try/Catch, or Try/finally. It's one shortcoming that I'd like to see them alter, I know there's functional ways around it, but oh well.
Quote:
|
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.
|
You keep mentioning standard components, for the purposes of errors/logging, how do you generally maintain unform messages and logging with this try/catch methodology? Generally we try to keep our programs in 4 seperate sections: a Data layer (data collection, base IO), a Logic layer(data manipulation), a UI layer(user input, display) , and a utilities layer (structures for base types, INI readers, logging/error handling, etc.) As a general rule all will have access to the Util layer, UI will see the Logic, and the Logic will see the data layer*. Using a try/catch (without the benefit of a custom error handler) an excpetion in the data layer would need to move to the Logic layer, then either continue moving up, or get re-thrown to the UI layer to effectively display the event. However, oftentimes execution in the Logic layer, should be unaffected by a problem in the data layer, rather the Logic layer notes the problem and moves on. Might an try/catch method be better for such cases, and if so should a custom error handler/logger be removed from this scenario?
Quote:
|
Neither VB.Net nor C# have checked exceptions, so I'll have to descend into Java
|
This point is one of your strongest, and now that I better understand what you mean I'll try to provide a better explination for my thoughts. In java this might be necessary because (and correct me if I'm wrong) you never leave the virtual machine of the java world, what occurs in java stays in java.
In .NET this isn't always the case. You can have external (and even non managed) code in the stack. If used to relying on exceptions, exceptions that pass through non-managed code can have unexpected results, yes good practice says that you should catch any exceptions before moving boundaries from managed to un-managed, but often times I've seen coders neglect this recommendation, either out of ignorance, or out of (usually undeserved) trust in the non-managed code.
-MBirchmeier
I know we're starting to drift a bit off topic (I hope no one minds because I think it's getting interresting) if we're too far off topic though perhaps we should move this to PMs
*: This level of seperation might seem excessive, but there's reasoning behind it. We do a lot of assembly line and Device related operations. Which means we get in data from a lot of different sources in a lot of different formats, (open ports, serial feeds, t/ftp, databases, snmp etc) however the data contains the same pertinant information. The Logic Layer is (usually) independant as possible, only relying on interface information from the data layer to collect the raw data, and manipulate it as necessary. The UI layer relies on interfaces from the logic layer, but different installations require different UI requirements. (the util provides cross layer utilities such as error handling, so that a problem in the DataLayer can provide notification in the UI layer if necessary, without needing to muck up the Logic Layer's execution.) This means that (hopefully) at a new installation we need to write data extracters to collect their data, possibly a custom UI depending on what they want, and the rest is gravy.