Re: Try Finally...

From: Bjørge Sæther (bjorge_at_hahaha_itte.no)
Date: 10/26/04


Date: Tue, 26 Oct 2004 13:09:10 +0200

L D Blake wrote:
> On Tue, 26 Oct 2004 09:17:52 +0200, "Bjørge Sæther"
> <bjorge@hahaha_itte.no> wrote:
>
>> In another posting you (finally) described the problem - that the
>> exception handler procedure was set in sysutils.pas. A good point.
>
> That's not the only problem. There's a lot of just plain fat on the
> whole thing too. While I can see why the primary proponents of OOP
> would want to do *everything* with objects, there is a breakpoint
> loosely defined about the point where using an object really doesn't
> bring about an improvement in overall result. This is one such case.
> Standard SEH (in windows, not delphi) provides a dword exception
> code, a number. Bloating this up to an object 8 to 10 times bigger
> does not improve Delphi's ability to deal with exceptions... it only
> provides semantic uniformity ... "On ExceptObj do" as opposed to
> "Case ExceptCode of" ... why bother... "Case" is an existing language
> construct that need not be reinvented to do a perfectly adequate job
> in this case... so why do we need "On".

I find the Exceotion objects very handy, because I don't have to deal with
codes at all. In fact I rarely knw what's happened that causes an exception.
I just fill in additional info and reraise the exception so that I get all
Info I can once it all unwinds. Ideally one should normally be able to do
other things with an application in case of a failure in a non-essential
part. I mean, the report generator shouldn't close down the application
because of some printer driver failure or my own bug.

> As i've pointed out in other messages, I don't care if the result is
> VCL or RAD compatible... I refuse to use that stuff anyway. What I
> am concerned with is consistent behavior, speed and stability. ...
> none of which are provided by the current Delphi exception handlers.

But what we have in common, and could possibly discuss, was how exception
handling should work - OO or not. You don't want to include the SysUtils.pas
anyway, so you have no problem writing your own exception handler. There's
nothing in the semantics of the try..except..end that stops you from writing
exception handling using codes, is it ? Honestly, I've produced a lot of
exceptions over the last 9 years. A *lot*. And it took me a few years to get
exception handling right. Not because of the objects, I just didn't
understand what would be the correct overall strategy. To me exception
objects work like a charm. It's really one of the more elegant parts of
Delphi, if you ask me.

To our little "conflict": You want a "built in" handling of exceptions, with
error codes and a distiction between catastrophic and non-catastrophic
failures. I prefer to have it like implemented today.
Isn't the solution: "To all those A4-programmers, it's handled in sysutils,
and you bit tweakers can roll your own" an OK compromise ? Don't be afraid,
there are not very many programmers who won't include sysutils.pas. I agree
if you state that the exception handling stuff should be well documented.
Even if one would never change anything, one needs to know that sysutils.pas
affects exception handling, IMHO.

One thing - I would love to have thread exceptions handled without a need
for writing ones own handler.

>> I just wonder how I
>> or anyone else would be able to guess what this was all about.
>> I'd say it's a documentation problem.
>
> Nope... it's bad design... there's no excuse for releasing a language
> in which keywords can and do simply stop working.

I agree. But if it would never stop working, then you would not have an
option on how to do it, would you ?
There are more things here - in the zone between pure compiler magic and the
VCL source code. Take TObject - it's all declared like a regular class, but
it doesn't behave like one - semantically. What about all the _XXXX routines
in system.pas - handling a lot of conversion & allocation behind the scenes,
while it is also compiler magic involved.

>> If one is about to count bytes, a *lot* of things should be
>> different in Delphi. At the cost of ease, I believe.
>
> I *refuse* to use the VCL and RAD tools. I am the programmer, not the
> Delphi IDE and I will decide on a keystroke by keystroke basis what
> goes into my programs. I do not want auto-generated this or
> smart-included that... I want to write code.

Same here. I do not use it intensively. But some parts are good.

> I write my code from
> scratch in a third party IDE called Context... My minimum size for a
> GUI "hello world" is about 12k, for Console mode it's about 9k. Not
> that this is a big hairy deal but done the VCL/RAD way the results
> are 320k and 87k respectively.

Now my only question is: "Why on earth Delphi?" Isn't that much like trying
to have your partner being another person ?
I have a few examples on similar stuff:
- WinXP is reported to have big problems with some DOS applications. Maybe
not a bomb, as the DOS stuff is getting really marginal.
- Delphi 'object' type is reported to have bugs regarding initialization.
Not too surprising, as Borland told back in '95 that these objects were not
part of the future.
- Floppy disks are getting poorer every day(my opinion), or at least, they
were the last time I owned a box of them. Most Internet shops sell *1*
Floppy drive model, just to please the old fashioned customers. I find
floppies far too unreliable to use for storage at all. No wonder if
development & quality efforts are routed elseghere...

>> Why don't you just provide the necessary routines to replace the
>> ones found
>> in SysUtils ?
>
> And put them where? In another unit, so that try/except can once
> again drop dead because you didn't include this new unit?
>
> Doesn't exactly solve the problem, does it?

You need to decide *who's* problems you're gonna solve. *You* would never
forget your own handler unit, would you ? I don't want it (for now, at
least), so it's not a problem. I would have a hard time being able to throw
out the sysutils.pas anyway...
What reminds, then, is if you wanted to release a unit for "alternitve"
Delphi programming. I have no answer to how that could be done. OK, rewrite
system.pas. It's perfectly OK.

-- 
Regards,
Bjørge Sæther
bjorge@haha_itte.no
-------------------------------------
I'll not spend any money on American Software products
until armed forces are out of Iraq.


Relevant Pages

  • Re: Question for Randy or Frank
    ... This is an HLA standard library facility. ... >> that you won't get under Windows. ... Then there's the "exception handling" approach to errors (which the HLA ... rather than solely "one big exception handler" wrapping the entire program ...
    (alt.lang.asm)
  • Re: Structured Exception Handling (was: Try Finally...)
    ... >> exception handlers and termination handlers. ... >> exception filtering, except clauses, and finally clauses, is up to ... > exception handler related to the stopping exception filter. ...
    (comp.lang.pascal.delphi.misc)
  • StackWalk behaviour
    ... I am adding an exception handler to certain of our build configurations ... actually dump the callstack for each thread. ... the second and third seemed to result in a valid callstack. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Problems Handling Errors Correctly
    ... Just because you have an exception handler, that doesn't mean it's exceptional for the exception handler to exist. ... Even absent exception handling, the correct thing to do is just try to open the file; if an error happens, then you present the user with some specific information about the error, based on the error code. ... If the error doesn't make sense in the context of the user's operation, then you don't report it to them. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Practical error/exception handling...
    ... > try-except blocks until they reach the exception handler that really ... > If you have a catch-all exception handler, ... > the stack to the next exception handler. ... Raptor squirms in seat, ...
    (alt.comp.lang.borland-delphi)