Re: Oh boy, how did we miss this...

From: Maarten Wiltink (maarten_at_kittensandcats.net)
Date: 11/08/04

  • Next message: Marco van de Voort: "Re: Is there an event just after the creation of all components of a form?" 
    Date: Mon, 8 Nov 2004 14:03:27 +0100

    "L D Blake" <not@any.adr> wrote in message
    news:6niuo0tt1ieqgf1m66led6nkgardoipm79@4ax.com...
    [...]
    > Borland made a mistake with their exception handling... They are
    > trying to use the OS's own reporting mechanism in a way that was
    > never intended (at least not by M$).

    Bollocks. It's an extensible mechanism, and Borland extended it.
    So, I bet, does Microsoft's own C++ compiler. From an OO software
    engineering perspective, it's sound.

    You've always insisted that what the OS offers must be right, and
    must be sufficient, and never wanted to accept that Object Pascal
    has the right to specify its own behaviour with respect to exception
    handling. There is no contract written in blood anywhere that says
    language designers and compiler vendors must restrict themselves to
    what the OS offers. Do you resent the very existence of Assign and
    Rewrite?

    [...]
    > Structured exceptions are used to report Asynchronous errors... stuff
    > that happes outside our code, out there in the real world...

    Everything asynchronous can be done synchronously, too.

    > here's a list of some of the stuff windows thinks it should report by
    > SEH...

    <snip list>

    > Now take a look at this... none of these are exactly trivial errors,
    > especially in a system of modern complexity. Divide by 0 is not a
    > runtime error (no matter what Borland says it is) it's the CPU telling
    > you it's in trouble... look at the list, access violations, overflows,
    > underflows, priveledged instructions... not trivial at all.

    So what _would_ you do about a division by zero? Throw your hands in the
    air and give up? You can do that by terminating the process in ISR #0,
    you don't need any complicated exception handling for it. But it might
    make perfect sense to simply skip the display of an average when there
    are no samples. Sure, you could test for n=0 beforehand. But catching
    an EDivByZero exception _works_ (if exception handling works at all)
    and has the advantage of segregating out error handling code. Yes, you're
    trading execution speed for program clarity. Software engineering is
    like that.

    [...]
    > The third level is enacted by the return values ...
    >
    > As much as I hate to agree with M$, the fact is they've chosen wisely
    > in the way they've set this up. They could have simply had *everything*
    > generate exceptions, but there's really no much point stopping a system
    > because of trivial errors. Exceptions are errors that windows thinks
    > are of such severity as to need *immediate* attention... and if they
    > don't get the attention they need your appy will be shut down by
    > Windows.

    Exception _handling_ means you *don't* have to halt and catch fire in
    response to every trivial little exception. And, as per the above, it's
    situation-dependent if a major error can't simply be ignored. Sometimes
    it can't, and we'll find out soon enough that we can't reasonably
    continue when Important Object X is null. But if the printer is offline,
    well, we tell the user that and carry on without printing. The hardware
    interface may well be such that this condition is reported through an
    interrupt which is translated into an (OS) exception. That's just an
    implementation detail.

    > Borland has chosen to overlay this important error reporting mechanism
    > with a layer of *deliberate obfuscation* that in fact hides a lot of
    > sins in their code.

    The excellent features added by this overlay have been explained to you
    a hundred times already, and you've chosen to not listen. WE USE THOSE
    FEATURES, WE LIKE THOSE FEATURES. And you don't. You may not like having
    to stop for a red light, either, but other chicks appreciate having their
    opportunity to cross the road.

    And as there is no obfuscation, there are no sins. Things are done
    differently; that's allowed (I will refrain from social commentary here).
    Nothing is broken as far as the OS can see, in fact it doesn't even see
    that things are done differently. You as a Delphi programmer can, but
    it's done by Delphi's rules, which don't break the OS's rules. There
    is a difference between doing something differently to indistinguishable
    effect, and doing it exactly the same way. Computers don't care.

    > Take a look at the way objects are created... why do they need an
    > entirely separate exception handler in their new instance code?

    This, too has been explained, albeit not quite as often. It is defined
    (by Object Pascal) that when an exception occurs in a constructor, the
    destructor is called. Clearly this requires exception handling, so it
    can't be wrong to have it.

    > Then to make it worse they split the handlers across two files --
    > something any programmer worth salt would never do-- leaving the
    > potential for disaster when exceptions don't get handled by Delphi.
    > No Delphi doesn't translate exceptions into runtime errors... It
    > IGNORES them and windows shuts down the appy.

    In a simple program, that might be what you want. And if you want the
    full deal, Delphi exception objects and Object Pascal exception handling,
    you include SysUtils. Just like it says in the help file. You don't have
    to like it, but you don't have plausible deniability any more.

    > Error handling by objects that, by the way, don't even have the error
    > codes in them... is a ludicrous perversion of a perfectly sound and
    > necessary error reporting scheme.

    No, it's a useful and perfectly sound extension of it. And they don't
    _need_ the error codes; the error codes are replaced by a different,
    more complex and more functional categorisation of errors.

    And it's not necessary; other OSes have existed and worked for decades
    without integrated exception handling. They may have been more eager
    to terminate user processes at the first hint of trouble, but that's
    a different story.

    > It is even worse when it quits working if you don't load the right
    > units...

    You're *right*. Now stop complaining.

    > If I wrote code like that even 10 years ago I'd have been fired by
    > everyone in the company who could fire me. Today it's a "feature"...
    > really, I don't care how much you like Delphi, you seriously do need
    > to ask yourself... what's wrong with this picture?

    Exactly one thing, to wit that you can't see past the limitations set
    by the OS's implementation and use of the idea of exceptions.

    Windows doesn't have the patent on exceptions. Other parties are free
    to design, implement, document, and use their own take on the general
    idea.

    Groetjes,
    Maarten Wiltink

  • Next message: Marco van de Voort: "Re: Is there an event just after the creation of all components of a form?"

    Relevant Pages

    • Re: Practical error/exception handling...
      ... Could I humbly suggest that the requirement for a 'standard' way of handling ... But I only need the exception handler in ... > and is informative to both user and developer when errors occur. ...
      (alt.comp.lang.borland-delphi)
    • Re: Error handling - Resume vs Exit
      ... I always wondered why Access wizards created simple exception ... handling code in the fashion they do. ... Use a separate subroutine for each try block. ...
      (microsoft.public.access.modulesdaovba)
    • Re: Ignore SQL Server 2000 store proc errors and still get results?
      ... catch (Exception ex) ... > You definitely don't want to do 30 round trips by handling the logic ... > temp table in your stored procedure to handle the collection of valid ... >>> expensive in both server and client code. ...
      (microsoft.public.dotnet.framework.adonet)
    • Re: Rationale behind unwind-protect and double errors
      ... try/finally exception handling system. ... C++ programmers usually use destructors for the same purpose. ... handling, which does not use the mechanism you outline. ...
      (comp.lang.lisp)
    • Re: on error against try..catch
      ... This is one point where try/cast can help as you can catch only those ... exception that are of a given class. ... > in some routine like mousemove, graphical drawing etc i sometimes i use ... >>> if exception handling is better like i think how can i do to pass from ...
      (microsoft.public.dotnet.general)