Re: Oh boy, how did we miss this...
From: Rob Kennedy (me3_at_privacy.net)
Date: 11/08/04
- Next message: Maarten Wiltink: "Re: Oh boy, how did we miss this..."
- Previous message: Rob Kennedy: "Re: Oh boy, how did we miss this..."
- In reply to:(deleted message) L D Blake: "Re: Oh boy, how did we miss this..."
- Next in thread: Rob Kennedy: "Re: Oh boy, how did we miss this..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 08 Nov 2004 11:13:48 -0600
L D Blake wrote:
> On 08 Nov 2004 08:14:32 GMT, vbdis@aol.com (VBDis) wrote:
>> Now I've tried to explore the error handling, by dereferencing an nil pointer.
>> This error seems to trigger SEH immediately, but no handler responded because I
>> had intentionally excluded SysUtils.
>
> 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$).
Where are Microsoft's intentions documented? URL, please. I'm expecting
to read a passage something like this: "Microsoft intends SEH to be used
only for X, not extended for Y or Z."
> Structured exceptions are used to report Asynchronous errors... stuff that
> happes outside our code, out there in the real world... here's a list of some
> of the stuff windows thinks it should report by SEH...
>
> STATUS_ACCESS_VIOLATION = $C0000005;
> STATUS_NO_MEMORY = $C0000017;
> STATUS_ARRAY_BOUNDS_EXCEEDED = $C000008C;
> STATUS_FLOAT_DENORMAL_OPERAND = $C000008D;
> STATUS_FLOAT_DIVIDE_BY_ZERO = $C000008E;
> STATUS_FLOAT_INEXACT_RESULT = $C000008F;
> STATUS_FLOAT_INVALID_OPERATION = $C0000090;
> STATUS_FLOAT_OVERFLOW = $C0000091;
> STATUS_FLOAT_STACK_CHECK = $C0000092;
> STATUS_FLOAT_UNDERFLOW = $C0000093;
> STATUS_INTEGER_DIVIDE_BY_ZERO = $C0000094;
> STATUS_INTEGER_OVERFLOW = $C0000095;
> STATUS_PRIVILEGED_INSTRUCTION = $C0000096;
> STATUS_STACK_OVERFLOW = $C00000FD;
> STATUS_CONTROL_C_EXIT = $C000013A;
>
> Now take a look at this... none of these are exactly trivial errors,
> especially in a system of modern complexity.
Array bounds exceeded? That's trivial. Control+C? That's trivial. I
handle it all the time in my multi-threaded console programs. Inexact
floating-point result? That's a condition that occurs so frequently I
wouldn't even expect that to be an error at all.
> 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...
If the CPU were really in trouble, there would be smoke billowing from
your computer.
I've asked you this before, but I don't think you answered: How did you
handle exceptions two years ago, before you understood what role
SysUtils played? Can you give an example of what kind of code an
"except" block would contain in one of your programs?
> The second level is that of error reporting (GetLastError). The concept here
> is simple. Each subroutine generates an error code and stores it for the
> procedure to call up on demand. This is a loosely synchronous error handling
> as the errors can only arrise from programmed actions but we are not underany
> immediate obligation to check the results ... bad flags, uninitialized
> pointers and such. These codes generally i/o related do not really signal
> 'system in trouble' and don't generate exceptions...
... except in my programs, where I use Win32Check and
RaiseLastWin32Error to convert the API errors into Delphi exceptions.
This greatly simplifies my code.
> 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.
The application is allowed to raise its own exceptions. (If it weren't,
the RaiseException API function wouldn't exist.) They can act the same
way as the operating system's. If they don't get handled, they may
terminate the program. But that's a choice the program developer makes
-- which program circumstances warrant exceptions and which don't.
> 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.
Handling SEH exceptions isn't a simple matter. There's bound to be some
complicated code involved. If I had a C++ compiler installed and the
inclination, I'd see what sort of code gets generated for "__except" and
"catch" clauses. I'm sure it wouldn't be simple.
> Take a look at the way objects are created... why do they need an
> entirely separate exception handler in their new instance code?
Read the OPLG lately?
> 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.
You keep on talking about disaster. I don't buy it.
> No Delphi doesn't translate exceptions into
> runtime errors...
In fact it does. When an exception makes it all the way to
ExceptionHandler, run-time error 217 occurs.
> It IGNORES them and windows shuts down the appy.
That's exactly what would have happened anyway. So what?
> Error handling by objects that, by the way, don't even have the error codes in
> them...
Guess again. Exceptions that come from the outside world all descend
from the EExternal class. Not only does that class have the error code,
but it also has the entire TExceptionRecord.
Exceptions that come from within Delphi all have the same error code, so
it's meaningless within a Delphi program. Why carry around a meaningless
error code?
> is a ludicrous perversion of a perfectly sound and necessary error
> reporting scheme. It is even worse when it quits working if you don't load
> the right units...
So include the right unit (singular, not plural) and be done with it.
You keep making a big deal about this. What will it take for you to get
over it?
> 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?
I don't really know, but I'm sure you'll tell us.
-- Rob
- Next message: Maarten Wiltink: "Re: Oh boy, how did we miss this..."
- Previous message: Rob Kennedy: "Re: Oh boy, how did we miss this..."
- In reply to:(deleted message) L D Blake: "Re: Oh boy, how did we miss this..."
- Next in thread: Rob Kennedy: "Re: Oh boy, how did we miss this..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
