Hi all,
I've only recently begun using exceptions in my code. I certainly see their
power, and I could see entirely doing away with error codes. However, in
reading some of the posts in various groups, it seems that some people feel
that exceptions are for situations that are not generally recoverable.

Pete, If you are *really* interested, I suggest that you research
  the historical discussions starting with something like a
  www.google.com search for objectpascal and exceptions. There is a
  lot of good material out there. Regards, JohnH
  

I found the time invested in reading "Exception Handling" by Flaviu Cristian
  extremely well spent.
  The paper is available at ftp://ftp.cs.ucsd.edu/pub/team/exceptionhandling.ps.Z
  --- Raoul
  

"Raoul De Kezel" <✉hotmail.com> wrote in message
    news:✉forums.inprise.com...
    (snip)
ftp://ftp.cs.ucsd.edu/pub/team/exceptionhandling.ps.Z
    (snip)
Raoul, thanks for the link! I downloaded it...
    now, how do I make it readable? (It's been 10 years since last time I had to

Raoul,
      Thanks. That looks like a long (academic) read, but I think I asked for it.
      Kristofer, I pushed it through acrobat distiller. There's a pdf at
      http://www.pdmagic.com/download/exceptionhandling.pdf.
      -pete

"Pete d'Oronzio" <✉pdmagic.com> wrote in message
        news:3b76fb2c$1_1@dnews...
        (snip)

Thanks, I'll go pick it up there!
        Kristofer
        

"Pete d'Oronzio" <✉pdmagic.com> wrote in message
        news:3b76fb2c$1_1@dnews...
        (snip)
Ps. I had a look at your website, how come there's no Delphi in it?
        is Delphi just your hobby?
        Kristofer

aarg. Caught.
          I own a company that produces a program for analysis of automobile crash
          records. It is used by traffic enginners to make cities safer to drive in.
          The program is called Intersection Magic and it is written in BP7.
          When Borland bagged OWL and started with VCL I had too much to do supporting

"Pete d'Oronzio" <✉pdmagic.com> wrote in message
            news:3b786ae9$1_1@dnews...
            (snip)
couple of
            (snip)
a
            (snip)
see a

In article <3b76f692$1_1@dnews>
      "Kristofer Skaug" <✉skaug.demon.nl> wrote:
      (snip)

I use ghost for all my PostScript needs.
      http://www.cs.wisc.edu/~ghost/gsview/
      -- Barry

"Pete d'Oronzio" <✉pdmagic.com> wrote in message
  news:3b76b1c3_1@dnews...
  (snip)

Pete,
  I'm not sure what you have already read, but back in June we had a big
  discussion on this issue under a thread which yours truly initiated under

Kristofer,
    I hadn't considered that fact that I'll be at the whim of those writing my
    libraries, but I suppose I could write wrappers if I decide to standardize
    one way or the other. I've done that in most cases for portability anyway.
    You say you're not interested in another major discussion, so I'll respect

"Pete d'Oronzio" <✉pdmagic.com> wrote in message
      news:3b76fd23$1_2@dnews...
      (snip)
writing my
      (snip)
standardize
      (snip)
anyway.

I think there are two objections to the manner of using exceptions that you
  suggest. The first is that exceptions are heavy on cpu usage even when
  caught within the same mehtod/function. The second is that it makes for
  contorted code where a simple loop would have been both faster, less messy
  and more readable.

"Greg Lorriman" <✉bigfoot.com> wrote in message
    news:3b770d27_2@dnews...
    (snip)
user
    (snip)
alphanummeric
    (snip)

Basically what you are saying is that the "threshold" for generating

"Kristofer Skaug" <✉satserv.nl> wrote in message
      news:3b778917_2@dnews...
      (snip)

I meant to say, 'threshold .. is *related to* the... budget'.
      
      

"Kristofer Skaug" <✉satserv.nl> wrote in message
      news:3b778917_2@dnews...
      (snip)

Absolutely not! I am saying that it is unreasonable for MS Word to do
      anything other than abort if the user provides a false path in the open
      dialog. What is the programmer supposed to do? Is he supposed to attempt to

"Greg Lorriman" <✉bigfoot.com> wrote in message
        news:3b781c99_2@dnews...
        (snip)
to
        (snip)
needed.
        (snip)
? it is? if your program just detects that no such file (as specified) is

Greg
        (snip)

PMFJI...but I agree with Kristofer. In the case you describe, MS provides
        an informational message saying that the file path is invalid and then
        offers a suggestion to correct the problem. This type of action does not
        require exception handling to accomplish. When you acknowledge the message

(snip)
message
          (snip)
try
          (snip)
see my reply to Kristofer.
          (snip)
has
          (snip)
That the message is cryptic doesn't mean that rasing an exception was the

"Kristofer Skaug" <✉skaug.demon.nl> wrote in message
          news:3b784177_2@dnews...
          (snip)
is
          (snip)

The user presses "Open" or "Ok". The code in the OK/Open button could look
          like this :

(snip)
situations.
            (snip)
Yes I did. A slip on my part.
            
            
            

"Greg Lorriman" <✉bigfoot.com> wrote in message
            news:3b7848f8_1@dnews...
            (snip)
situations.
            Noted your self-correction point, that's ok.
            (snip)
parameters.

Yup, indeed you're going again. But this post has been most useful. Thanks
              for taking the time to do it.
              I follow all the logic, and agree with all of it, up to the last lines.
              (snip)

If I think of my block of code being a function, then I would describe the
              calling function as the 'big boss' in your terminology. If, for example, I

"Pete d'Oronzio" <✉pdmagic.com> wrote in message
                news:3b7867a6$1_2@dnews...
                (snip)
figure out
                (snip)
UpdateTimeStamp
                (snip)
terminate;

In article <3b78e505_1@dnews>
                  "Kristofer Skaug" <✉satserv.nl> wrote:
                  (snip)

Exceptions are mechanisms of error *information* propagation. They do
                  not increase error. They do not spread error. "Error propagation" is an
                  incorrect term. They are a mechanism for transactional-style

"Barry Kelly" <✉eircom.net> wrote in message
                    news:✉4ax.com...
                    (snip)

They are likely to increase and spread error if not intercepted,
                    depending on the way you program around them. The caller is forced to
                    take special measures so as not to be adversely affected by exceptions.

In article <3b7cd493_1@dnews>
                      "Kristofer Skaug" <✉satserv.nl> wrote:
                      (snip)

Use try..finally (or possibly try..except {do something}; raise end) to
                      enforce transaction-like behaviour.
                      (snip)
Don't program around them! Use them.

============================================
                         THE DEBATE FROM HELL PART XIV
                        ============================================
                        Before addressing any of your responses specifically, I just need to take
                        2 steps back and remind myself of the following: It is not the exceptions

"Kristofer Skaug" <✉skaug.demon.nl> wrote in
                          news:3b7d7ea6_2@dnews:
                          (snip)

I thought try-finally had no effect on performance, it's when an exception
                          is raised that performance is affected.
                          --

wrote in message
                            (snip)
exception
                            (snip)

the try-except blocks are much more of a problem for performance,
                            but what I was now envisioning was a sequence like this:
                            try

"Kristofer Skaug" <✉skaug.demon.nl> wrote in
                              news:3b7d8b76$1_2@dnews:
                              There was a post a while ago, about try..except and speed. With a call to
                              StrToFloat, the number of ticks was 400, when wrapped in try..except 417.
                              I'd think try..finally would be close to the same.

In article <3b7d8b76$1_2@dnews>
                              "Kristofer Skaug" <✉skaug.demon.nl> wrote:
                              (snip)

And how are you going to perform this differently in the absence of
                              exceptions; that is, using a motley collection error codes and ragbag
                              global variables, scattered hither and thither, every second statement a

"Barry Kelly" <✉eircom.net> wrote in message
                                news:✉4ax.com...
                                (snip)
a
                                (snip)
Excuse me, but error codes and local variables are not inherently
                                'motley' or 'ragbag'.

In article <3b7d9f9e_2@dnews>
                                  "Kristofer Skaug" <✉skaug.demon.nl> wrote:
                                  (snip)

My point is that exceptions are unified; they all descend from
                                  Exception, they have a standardized handling mechanism.
                                  I was just trying to use some literary devices to illustrate their

"Barry Kelly" <✉eircom.net> wrote in message
                                    news:✉4ax.com...
                                    (snip)

OK.
                                    (snip)

actually I rarely use any of those, I always try to get the error
                                    code directly from a call if at all possible.

"Barry Kelly" <✉eircom.net> wrote
                                      (snip)


While (slightly) in the pro-exception camp, I must mention that it
                                      is quite possible to have unified, non-ignorable error objects.
                                      I wrote the proof of concept below, which :
                                      - Represents errors with type Exception, and is therefore unified.

"Raoul De Kezel" <✉hotmail.com> wrote in message
                                        news:✉forums.inprise.com...
                                        (snip)

Raoul, that looks very interesting.
                                        I need some time to try it and "grok" it...
                                        Kristofer

In article <3b8028ff$1_1@dnews>, ✉skaug.demon.nl says...
                                          (snip)

Kristofer, the major point of this exercise is to show that
                                          the crux of the debate is manual vs automatic propagation
                                          of exceptions vs immediate shutdown. Nothing else, IMO.
                                          --- Raoul

"Raoul De Kezel" <✉hotmail.com> wrote in message
                                            news:✉forums.inprise.com...
                                            (snip)

Noted...
                                            Kristofer
                                            

"Barry Kelly" <✉eircom.net> wrote in message
                                news:✉4ax.com...
                                (snip)

(note: snipped [beeped!] some inflammatory passages... )
                                atomicised operations focused on handling errors close to the source
                                of error (for specific handling) can do with a lower degree of

In article <3b7f9bcc$1_1@dnews>
                                  "Kristofer Skaug" <✉skaug.demon.nl> wrote:
                                  (snip)

Why do you need to handle the errors? If you really need to handle the
                                  errors, then (IMO) the operations should be in completely separate
                                  functions, so that you can eliminate the drudgery of handling the same

"Barry Kelly" <✉eircom.net> wrote in message
                                    news:✉4ax.com...
                                    (snip)

Correct, this is a factoring exercise and is usually incurred at some
                                    point (sooner or later) unless we are talking about a very very specific
                                    sequence (like a system self test sequence which is specified to abort

In article <3b7d7ea6_2@dnews>
                          "Kristofer Skaug" <✉skaug.demon.nl> wrote:
                          (snip)
LOL!
                          (snip)

I'd never suggest re-raising an exception if you didn't know where it is
                          going to go. Of course you must be aware of where it's off to; whether

"Barry Kelly" <✉eircom.net> wrote in message
                            news:✉4ax.com...
                            (snip)
is
                            (snip)

ok, there was just this standard 'raise;' part in each of your examples
                            above...

In article <3b7f9bce_1@dnews>
                              "Kristofer Skaug" <✉skaug.demon.nl> wrote:
                              (snip)


So you wouldn't be punished if there was a hole in your code and you
                              were using error codes?
                              And you consider this an advantage?

In article <✉4ax.com>
                                Barry Kelly <✉eircom.net> wrote:
                                (snip)

During printing, I hasten to add.
                                -- Barry
                                

"Barry Kelly" <✉eircom.net> wrote in message
                                news:✉4ax.com...
                                (snip)
if
                                (snip)

Generally yes, but not necessarily in such a nuclear bombing manner.
                                (snip)
didn't

In article <3b7fb52a_1@dnews>
                                  "Kristofer Skaug" <✉skaug.demon.nl> wrote:
                                  (snip)

No there aren't. You show me where the reasoning breaks down:
                                  * You can ignore error codes in your code and your code
                                  will continue blithely onwards to the next statement -

"Barry Kelly" <✉eircom.net> wrote in message
                                    news:✉4ax.com...
                                    (snip)

No: A fault would be, if StrToInt returned some value without somehow
                                    indicating that it is invalid.
                                    (snip)

OK let me take a swipe at that:

In article <3b802902_1@dnews>
                                      "Kristofer Skaug" <✉skaug.demon.nl> wrote:
                                      (snip)

The only way it can do that is for it to return a Boolean value, which
                                      you must check and either raise your own exception or show your own
                                      message, both of which would be non-standard - they would have to be

Hi Barry,
                                        I agree with your bottom line.
                                        A quick summary footnote from my side:
                                        - Firstly I was trying to describe the special fault tolerance
                                        requirements typically faced by my applications.

Greg
            (snip)
path
            (snip)

Why would you need to raise an exception here? Why not just open a dialog?
            Isn't the usual way to handle exceptions with try-except blocks? The idea
            is that you can interrupt the program's normal flow of control by catching

In article <3b7872c3$1_1@dnews>
              "J. M. De Moor" <✉nospamobjectpac.com> wrote:
              (snip)
About 95% of try..except blocks are a bad idea.
              -- Barry
              --

Brian
                (snip)
Don't know how scientific your 95% is but I'll go you one better. I think
                that the vast majority of raise statements are a bad idea.
                Joe
                

In article <3b78853d$1_1@dnews>
                  "J. M. De Moor" <✉nospamobjectpac.com> wrote:
                  (snip)

Please list some valid uses of exception-swallowing try..except blocks,
                  and I'll show you that the majority should have checked for error before
                  doing whatever raised the exception.

On Tue, 14 Aug 2001 03:16:12 +0100, Barry Kelly <✉eircom.net>
                    wrote:
                    (snip)

In a web module that saves the settings of a component with TWriter
                    and RTTI.
                    John McTaggart

"Barry Kelly" <✉eircom.net> wrote
                    in message
                    news:0d2hnt09m4r82qfpokg5a1pt36jd86jn0b@
                    4ax.com...
                    (snip)
exception-swallowing try..except blocks,

In article <✉4ax.com>, ✉eircom.net says...
                    (snip)

Catch a database deadlock exception. Retry (once) the transaction.
                    Catch "TCP/IP connection broken" when writing. Try to reconnect and rewrite (once).
                    Catch an AV exception. Stop and restart the unattended application.
                    ....

On Tue, 14 Aug 2001 03:16:12 +0100, Barry Kelly <✉eircom.net>
                    wrote:
                    (snip)

I tend to mute all exceptions in the execute block of a thread, for
                    instance (otherwise the app has a mysterious tendecy to suddenly
                    dissappear). I often catch exceptions raised by TFilestream, so the

"Barry Kelly" <✉eircom.net> wrote in message >
                    (snip)

Of course, but that doesn't mean we can't use them to our advantage. Here is
                    a common one that I use all the time. (And I mean, ALL THE TIME).
                    While I am working on creating a new procedure for Interbase, initially, the
                    procedure doesn't exist. However, as I'm working on debugging the code and

In article <3b7993bf$1_1@dnews>
                      "Woody" <✉ih2000.net> wrote:
                      (snip)
I'm far from certain that exceptions are the correct method for handling
                      database "errors", because database "errors" aren't really errors; they
                      are very much run-of-the-mill conditions that happen day-in day-out.

In article <✉4ax.com>, ✉eircom.net says...
                        (snip)

Precisely. They are exceptions to the standard behavior, and it
                        therefore makes sense to report them with exceptions.
                        It is somewhat common these days to read that exceptions should
                        be used to report errors and only errors. This statement goes

"Raoul De Kezel" <✉hotmail.com> wrote in message
                          news:✉forums.inprise.com...
                          (snip)

He he, finally.
                          If we could only agree on some terminology, like the " Fault / Error /
                          Failure " definitions in the "Error handling for Business Information

In article <3b7cdda9$1_1@dnews>, ✉satserv.nl says...
                            (snip)

Yes, mostly. Exceptions should be used to report
                            exceptional behavior. What's exceptional is indeed
                            specified by the designer of the function. But
                            like any good design, this specification is in turn

"Raoul De Kezel" <✉hotmail.com> wrote in message
                              news:✉forums.inprise.com...
                              (snip)

well, "useless" maybe a little harsh. But they may not conform with your
                              strategy and therefore need "reworking". Seldom are you in a position
                              where all the code is written by the same team, using the same strategies

In article <3b7cf1bc_2@dnews>, ✉satserv.nl says...
                                (snip)

Well, I meant that we dont have so much freedom when
                                defining useful exceptional behavior. For example, here
                                is an arbitrary - and useless - exception behavior :
                                function Factorial(N : Integer);

In article <✉forums.inprise.com>
                          Raoul De Kezel <✉hotmail.com> wrote:
                          (snip)

No, their not. A file-system error is an exception to run-of-the-mill
                          coding; you don't expect your .SaveToStream method to have to handle a
                          file-system running out of space.

"J. M. De Moor" <✉nospamobjectpac.com> wrote in message
              news:3b7872c3$1_1@dnews...
              (snip)
dialog?
              That's what happens anyway.
              Let's say that the existence of a path isn;t the only validation that needs

"Raoul De Kezel"
    <✉hotmail.com> wrote in
    message
    news:MPG.15e0fcd333d3013e989730@forums.i
    nprise.com...

(snip)

So did it for me :-)
      (snip)

True, but incomplete, IMO. The called function
      should ideally raise an exception when sequential
      execution of caller code is meaningless (because
      the standard service cannot be provided)

"Raoul De Kezel" <✉hotmail.com> wrote in message >
        (snip)

Stronger yet, in my experience it is a rather unique case if the called
        function can make such a judgement, lest it has a *very* application
        specific task [inherently tied to the task of its caller, such as a code
        block within a function], a local (nested) procedure, or perhaps a recursive

(snip)
I know of Oracle PL/SQL, the experimental language SESAME, and
          of course all pure functional languages. There must be others,
          but I am not a language freak :-)
          (snip)
C++, sort of. Many others, I guess.
          (snip)
The nearest thing I know of is the paper "Error handling for Business

"Raoul De Kezel" <✉hotmail.com> wrote in message
            (snip)
http://www.objectarchitects.de/arcus/cookbook/exhandling/
            Thanks Raoul, that looks like a very interesting resource!
            Kristofer
            

In article <✉forums.inprise.com>
        Raoul De Kezel <✉hotmail.com> wrote:
        (snip)

It isn't very difficult in Object Pascal with correct use of
        try..finally.
        (snip)

Specification of anticipated exceptions is a misguided dead-end.

(snip)

Barry, please dont take it bad, but I think this is a pretty naive
          sentence.
          (snip)
That's a very bold statement :-)
          --- Raoul
          

"Barry Kelly" <✉eircom.net> wrote in message
          news:✉4ax.com...
          (snip)

For simple things I agree (e.g. reclaiming a chunk of memory, closing a
          file etc). However in more complex state machines, an unhandled exception
          generally means "game over" unless you add a *lot* of recovery code.

In article <✉newsgroups.borland.com>
                      ✉tech-medic.com (John McTaggart) wrote:
                      (snip)

Show me the code. Show me where it uses exceptions for failure, and
                      doesn't check error conditions before it causes an exception.
                      -- Barry

In article <3b7932c6_1@dnews>
                      "Kristofer Skaug" <✉satserv.nl> wrote:
                      (snip)

It depends on the quality of the input data. If it is user sourced, the
                      user should see the error. If it is highly desirable to continue at all
                      costs, error conditions should probably be determined before an

In article <✉forums.inprise.com>
                      Raoul De Kezel <✉hotmail.com> wrote:
                      (snip)

There's no argument, then.
                      (snip)

It depends on the quality of the input data. I'm far from sure that the
                      appropriate mechanism for failure of database committal is an exception,

In article <✉4ax.com>
                      Lord Crc <✉hotmail.com> wrote:
                      (snip)

Pre D6, yes. You must have a bed-rock of exception handling, unless you
                      want all error conditions to be fatal.
                      (snip)

There, I think that's a bad idea.

In article <✉4ax.com>, ✉eircom.net says...
                        (snip)

There is no way we can predict beforehand that a network
                        connection or a target machine will break on next use.
                        Whatever the quality of the input data....
                        --- Raoul

"Barry Kelly" <✉eircom.net> wrote in message
                        news:✉4ax.com...
                        (snip)

Think of your application in the vertical way, composed of chains of
                        functions calling other functions to get an ultimate task done. There is
                        a reasonable likelihood that your lowest levels of code will consist of

"Barry Kelly" <✉eircom.net> wrote in message
                        news:✉4ax.com...
                        (snip)

What's different about this in D6?                         acquired D6 personal and didn't start using it yet>
                        (snip)
or

In article <3b7cdabb_2@dnews>
                          "Kristofer Skaug" <✉satserv.nl> wrote:
                          (snip)

Not try..except; try..finally. Perhaps the odd
                          try
                          except

In article <✉forums.inprise.com>
                          Raoul De Kezel <✉hotmail.com> wrote:
                          (snip)

That information is external to the program, and enters it through
                          function calls; thus, it is still input data.
                          -- Barry

In article <3b7cdbc6$1_2@dnews>
                          "Kristofer Skaug" <✉satserv.nl> wrote:
                          (snip)

There is a try..except that protects the TThread.Execute method; before
                          the application would just fall off a cliff, unless you had your own one
                          in .Execute.

In article <✉4ax.com>, ✉eircom.net says...
                            (snip)

Barry, I'm afraid something is not getting through. I am trying
                            to say that checking at time T that a connection is alive wont
                            tell us anything about its state at time T + 1 microsec, when we
                            perform a write.

In article <✉forums.inprise.com>
            Raoul De Kezel <✉hotmail.com> wrote:
            (snip)

It's pretty easy. Expect exceptions everywhere. Any time you do
            anything, think what will happen if an exception occurs right now; most
            of the time, nothing much bad will happen.

In article <✉forums.inprise.com>
                              Raoul De Kezel <✉hotmail.com> wrote:
                              (snip)

Yes. I lost the context of the thread, due to a problem with NTFS this
                              morning; I only downloaded the latest 500 headers.
                              (snip)

But the problem can still be dealt with in a transactional style, yes?

t thrown up by lower layers.
              (snip)
// initialize
              (snip)
// commit
              (snip)
// finalize
              (snip)
basic Delphi: The finalize block is ALWAYS executed

"Barry Kelly" <✉eircom.net> wrote in message
                            news:✉4ax.com...
                            (snip)

If I read your code right, you want exceptions re-raised to go all the
                            way up, regardless.
                            I don't understand it. Exception handlers are there to catch / mask

"Barry Kelly" <✉eircom.net> wrote in message
                                news:✉4ax.com...
                                (snip)

I heard that!
                                Kristofer
                                

"Barry Kelly" <✉eircom.net> wrote in message
                            news:✉4ax.com...
                            (snip)
one
                            (snip)
Ah, interesting! so does TThread have an OnException/OnError event as
                            well?

"Barry Kelly" <✉eircom.net> wrote in message
              news:✉4ax.com...
              (snip)
my
              (snip)

The whole concept of a try - except - end statement, as promoted in the
              OP language guide, is implicitly justified and/or promoted by "expecting

(snip)

Yes. That's kind of what's been running through my mind. Were exceptions
                just put there to perform the same function as a safety net for a flying
                trapeze artist? I doubt it. That would a waste. In mose cases, if a
                routine exits unhappily and returns the user to the main program loop,
                that's about as good as crashing and re-starting the program. Who knows

In article <3b7d8864$2_1@dnews>
                  "Pete d'Oronzio" <✉pdmagic.com> wrote:
                  (snip)

The programmer who wrote the rollback procedures, either explicitly with
                  try..except ... raise; end or implicitly with a try.. {commit}
                  finally..end block.

"Pete d'Oronzio" <✉pdmagic.com> wrote in message
                  news:3b7d8864$2_1@dnews...
                  (snip)
Nice metaphor
                  (snip)

You may want to sniff around at www.optimalcode.com
                  I believe Bob Lee has some stuff about exception handling overhead too.

In article <3b7d95a9_2@dnews>
                    "Kristofer Skaug" <✉skaug.demon.nl> wrote:
                    (snip)

Only through "try {stuff} except end; "; otherwise, they will be
                    *visible*, and execution will be *aborted*. With ignored error codes,
                    the only warning you get is that stuff doesn't happen, or data loss, or

"Barry Kelly" <✉eircom.net> wrote in message
                      news:✉4ax.com...
                      (snip)
actively,
                      (snip)

I've addressed these questions elsewhere in this thread.
                      Kristofer

In article <✉4ax.com>
                Franz-Leo Chomse <✉samac.de> wrote:
                (snip)

What's your point? Do you think I don't know that?
                -- Barry
                

In article <3b7d7eac_2@dnews>
                              "Kristofer Skaug" <✉skaug.demon.nl> wrote:
                              (snip)

You don't. It just terminates the thread.
                              (snip)

You should attach a string to a fixed object, and make sure you're able
                              to follow it back should you get lost; only cut it if you make it

"Barry Kelly" <✉eircom.net> wrote in message
                    news:✉4ax.com...
                    (snip)

to me, error codes and exceptions are like democracy and
                    dictatorship, in that order.
                    Kristofer

In article <3b7d95ac_2@dnews>
                      "Kristofer Skaug" <✉skaug.demon.nl> wrote:
                      (snip)

I'm afraid I'm the reverse; exceptions *force* you to consider the
                      possibility of errors. Error codes are optional; an awful lot of code
                      can be written without regard for the error codes returned, and thus

"Barry Kelly" <✉eircom.net> wrote in message
                        news:✉4ax.com...
                        (snip)

so, isn't that pretty dictatorial?
                        (snip)
state,
                        (snip)

But errors are relative - one program's error can be another program's

In article <3b7f9bd0$1_1@dnews>
                          "Kristofer Skaug" <✉skaug.demon.nl> wrote:
                          (snip)

"OK, in our next framework, we don't really care about errors. If you
                          want to know if you're headed for la-la land, you're going to have to
                          ask. We'll happily let you drive off a cliff with all you're customer's

On Thu, 16 Aug 2001 23:45:52 +0100, Barry Kelly <✉eircom.net>
                        wrote:
                        (snip)

An "EWriteError in ...." is more friendly to the users?
                        (snip)

Hmmz... I did isapi modules a year ago, so i checked up the help on
                        TWebResponse.ContentStream and thought i must have dreamt that

In article <✉4ax.com>
                          Lord Crc <✉hotmail.com> wrote:
                          (snip)

That's not what happens. Try this program (stick it in a ExceptTest.pas
                          file and compile with dcc32), and stick in a non-number in the box:
                          ---8<---

On Sun, 19 Aug 2001 01:50:41 +0100, Barry Kelly <✉eircom.net>
                            wrote:
                            (snip)

Right, and i'll add this one to the list of "you know you've been
                            spending too much time in the IDE when:"
                            :)

In article <✉4ax.com>
                            Barry Kelly <✉eircom.net> wrote:
                            A mistake:
                            (snip)

Oops. These are the wrong way around.
                            ms.Free;

thanks for your feedback...
                              - Asbj?rn
                              
                              
                              

"Barry Kelly" <✉eircom.net> wrote in message
                                news:✉4ax.com...
                                (snip)

wow, so you see OnTerminate suddenly firing...
                                (snip)

Interesting metaphor!
                                Kristofer