Re: .NET has a broken Exception model

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Stu Smith (stuarts_at_nospam-digita.com)
Date: 05/11/04 

Date: Tue, 11 May 2004 16:01:42 +0100

(inline)

"Tom Porterfield" <tpporter@mvps.org> wrote in message
news:OihGex0NEHA.736@TK2MSFTNGP09.phx.gbl...
> William Ryan eMVP wrote:
> > Tom:
> >
> > I think his whole point is that System.Exception is a lame approach
> > but not using it requires quite a bit of code for this situation.
> > Take Cody's example directly and say that based on those exceptions,
> > he returns lets say a return code of 0. Now, if something more
> > severe happens or is outside of the bounds there, say the classic
> > OutOfMemory exception, System.Exception is going to catch it and
> > return a 0. There would be no differentiation between the two. Do
> > this in a class library that you distribute and you could really
> > obscure some ugly bugs.
>
> Reread what I said. I said SystemException, not System.Exception. There
is
> a distinct difference. All exceptions inherit from System.Exception.
> System.SystemException is the base for non-fatal or recoverable
exceptions.
> The problem comes in when what one person considers recoverable someone
else
> may consider fatal.

It's probably best, to avoid a neverending argument, to distinguish between
two sorts of fatal vs non-fatal:

1) Fatal exceptions as defined by the framework. They are
OutOfMemoryException, ExecutionEngineException, and StackOverflowException.
You simply can't catch them, except possibly within the unhandled exception
handler.

2) Fatal within the context of a block of code. So in the current example,
FormatException, ArgumentException and OverflowException are being
considered as non-fatal (ie they aren't going to be allowed out of this
stack frame). All other exceptions are outside the scope of that block of
code, and will unwind until some other block of code considers itself
capable of dealing with them.

I tend to use "fatal" for case (1) but I suppose you could use it for case
(2).

Personally, in the case of this thread, I'd say the problem is that there is
no Int32.TryParse or DateTime.TryParse (cf Double.TryParse) in the
framework, as opposed to a shortcoming of the exception system.

Stu

>
> > Personally in this situation I trap all my exceptions specifically
> > and don't really have a problem b/c I seldom do the same things for
> > different exceptions (actually, I never do unless it's an oversight)
> > so it's not really an issue to me, but if I wanted to trap those four
> > things and respond the same way to each of them like he mentions,
> > then it would cause you to write some extraneous code. But catching
> > System.Exception in an instance like this seems to be the worst of
> > all worlds (I mean no offense by this, just MHO). You can't possibly
> > know/anticipate and respond specifically to every possible exception
> > under the sun and assuming one wanted to make the argument they could
> > (mathematically it's possible), you'd defintiely write a lot of code
> > that you didn't know.
>
> No offense taken as you didn't read my original message correctly.
>
> It really depends on what the requirement is. If you only care about four
> specific exceptions then you have to filter in some way, either with
> distinct catches or a more generic catch and then throw if the exception
> isn't what you wanted. Like just about any problem, this one has multiple
> solutions, all with their own merit.
> --
> Tom Porterfield
> MS-MVP MCE
> http://support.telop.org
>
> Please post all follow-ups to the newsgroup only.
>

Relevant Pages

  • Re: Error handling: Whats recommended for Class Libraries?
    ... * framework designers should be allowed to throw and catch. ... application programmers should only be allowed to throw, ... The first one is that the framework APIs are designed so that exceptions are ... > the responsibility of the app programmer. ...
    (microsoft.public.dotnet.framework)
  • Re: Interface und Exception
    ... #In meinem Programm definiere ich ein Interface: ... Für mich liest dich das so, dass der OP das interface-Sprachkonstrukt aus ... fest sprachgebundene Exceptions noch ans Ziel ... nicht C++ mit WCF oder einem anderen Framework. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: A Programmers proposal for the Delphis roadmap
    ... tied to a specific framework version, ... backwards compatibility between framework versions and allow ... derived from System.Exception (in .NET 2.0 exceptions not derived from ... static void Throw ...
    (borland.public.delphi.non-technical)
  • Re: Englische Exception in VS2008 - Wie?
    ... dass mein deutsches VS2008 nur deutsche Exceptions ... deinstallieren kann gehe ich eigentlich davon aus, dass das Framework an sich ... deinstalliert - englischen Installer runtergeladen - aber die Installation ... Versionen davon) in Deutsch auf deinem System hast. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: Problems Handling Errors Correctly
    ... But as with your observation about the .NET Framework itself, to some extent this is a consequence of the sheer size of the Framework. ... One hopes that over time, the documentation will get filled in, but it's not hard to see why some things may have been considered lower priority and receive a basic "template" documentation rather than a fully useful description. ... the docs include a section immediately after the "Return Value" section enumerating possible exceptions. ... If it's not the case, or it's incomplete, or it leaves out exceptions that could be thrown my methods called from the method, that would really be a drag. ...
    (microsoft.public.dotnet.languages.csharp)