There's already a built-in global exeption handler... we just don't get to
see it when debugging. At runtime, when an unhandled exception occurs, the
runtime gives the user the option of continuing gracefully. I would argue
that .NET (at least VB.NET) already has global exception handling... you
don't need to add your own unless you want to record a log file or something
like that.
Anyway, in terms of when to use Try/Catch, I tend to feel that you only need
to use Try Catch for *expected* errors (yes, you read that correctly) and
when resource cleanup is essential. All other exceptions can be safely
bubbled up to the runtime or to your own global exception handler.
For instance (pseudocode mostly):
Dim fs as FileStream("C:\My File")
Try
fs.Write("somedata")
Catch
'do nothing
Finally
fs.Close
End Try
If you don't use the Try in the above case, if the Write statement throws an
error, then your file will remain open until your app ends. A similar
situation can occur with database connections and datareader objects.
P.S. On a similar note, IMHO, I think a lot of the classes in the framework
overuse exceptions. For instance, String.Substring raises all sorts of
exceptions if not used in precisely the right way (i.e.
String.Substring(0,10) on 5 character string will raise an exception) which
is why I prefer to still use VB's intrinsic and very graceful Mid/Left/Right
statements. There's no beating those classic B.A.S.I.C. statements.
"Michael MacDonald" <ma***********@yahoo.com> wrote in message
news:up*************@TK2MSFTNGP10.phx.gbl...
Thanks for the informative explanation. I will try using "Try" in my
next homework assignment and see if the proffesor notices I gave a
little extra effort! Whatever helps to get the "A" I always say.
Mike_Mac
*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!
