Re: Another shitty example of exceptions

From: Fabio Dell'Aria (thesun_at_inwind.it)
Date: 05/06/04


Date: 6 May 2004 01:59:17 -0700


"Skybuck Flying" <nospam@hotmail.com> wrote in message news:<c540vm$l1h$1@news4.tilbu1.nb.home.nl>...
> "Duncan McNiven" <duncan@mcniven.net> wrote in message
> news:d19a70tacc7ivl60ccjtrfqdpcb56h5sqs@4ax.com...
> > On Thu, 8 Apr 2004 00:03:07 +0200, "Skybuck Flying" <nospam@hotmail.com>
> > wrote:
> >
> > >The exception is handled (if it is handled at aaaalllll!!!) after the
> > >finally statement has executed !
> >
> > PLEASE TRIM YOUR QUOTES
> >
> > As coded, that is true. In most cases it makes sense to release the
> > resources you have allocated as soon as they are no longer needed. If
> > you need those resources to be still allocated in order to handle the
> > exception, code it differently. No problem there; move along folks.
> >
> > >HA HA HA
> > >
> > >What about turning the world UP SIDE DOWN.
> > >
> > >Faults are handled later on... and not on sight !
> >
> > Faults are handled by code that is written to do so. That code might be
> > at any level. Exceptions provide a mechanism to:
> > A. Move from a fault to code that can handle it
>
> Yeah and then everyone that examines the faulty code is gonna be like:
>
> "??? HUH WHAT THE *** ???"
>
> This code raises an exception ! WHERE THE *** IS IT HANDLED ?! =D
>
> So much for readable and clear code.
>
> > B. Release resources and do other clean-up tasks as necessary at all
> > intermediate levels along the way
>
> Sure buster ! Spread all your error handling and resources handling code
> across all of your source/application...
>
> Instead of handling where it should be handled !
>
> It will make your program even harder to understand ! =D
>
> > C. Avoid lower level code having to 'know about' higher level code
>
> ? Bull*** !
>
> > D. Avoid having to pass failure flags through a long chain.
>
> What's wrong with that... that's perfectly acceptable.
>
> It makes tracing a brease... you can just walk the code path
> from high to low and back again and see exactly where it goes wrong and
> how far it went :D
>
> Besides... exceptions go up and down the levels as well
>
> So this is bull !
>
> > E. Remove error-checking code from the normal flow of execution, thus
> > improving performance.
>
> Bull ! Exceptions introduce more overhead !
>
> It hides error handling which is bad !
>
> Error handling is part of any application !
>
> Technology and the world are far from perfect =D
>
> >
> > Exceptions are wonderful. They save so much work and code clutter, and
> > really improve maintainability. Exceptions are one of the best things
> > about Delphi compared to previous Pascal toolsets.
>
> Lol THE BIGGEST BULL*** LOL =DDDD

You can try EurekaLog (www.eurekalog.com).

EurekaLog is an add-in tool that gives to your application (GUI,
Console, Web, etc.) the ability to catch every exception (even those
raised by memory leaks) and every infinite-loops/deadlock bugs,
generating a detailed log of call stack (with unit, class, method and
line #), showing and sending it back to you via email.

--
Best regards...
Fabio Dell'Aria.

Quantcast