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
that. Thanks for your opinion, it's how I've operated until now. But I'm
considering a 180 degree turn. I don't think it's possible to decide to do
it halfway and have maintainable code. Seems like it must be one way or the
other.
I've tried to go back to June's newsgroup listings. Can't get back that
far. I'll find an archive and see if I can find "Exceptions should be
banned".
Thanks!
-pete
> "Pete d'Oronzio" <✉pdmagic.com> wrote in message
> news:3b76b1c3_1@dnews...
> >....<snip>
> > I'm not sure if this is a cut-and-dried question, or if I'm starting a
> > religious war. Either way, I'm very interested in the response.
>
> 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
> the title "Exceptions should be banned?".
> Rest assured that this theme does awaken lots of personal opinions related
> to programming style.
>
> Exceptions are being used everywhere, in the VCL, in the RTL, in third-party
> components. Unless you write all of your own code (including your own
> framework) it is unlikely that your program will be entirely consistent in
> terms of exception raising behaviour.
>
> From what I've seen in that discussion, the majority of Delphites believes
> strongly in an active usage of exceptions and relying on robust, state-free
> code combined with an intelligent top-level (default) exception handler. As
> you will also see from the referenced discussion, I am not among the
> Delphite majority in this respect.
>
> I am not eager to have another major discussion on this point now, but FWIW
> let me summarize my current opinion on this issue:
>
> I think it is inappropriate to raise exceptions for 'normal' error cases, or
> as a means of regular flow control; this, IMO, imposes too many constraints
> on the user of such code. I much prefer using error codes which enable me to
> decide how to react to an anomaly at the point where it happens (close to
> the source of error). In any case, exception-generating code (i.e. any code
> which uses Raise) should IMO be carefully documented as such.
> As for 'criticality' judgement on errors, there's the real catch (excuse the
> pun! <g>). How does a programmer (e.g. component writer) determine what is a
> 'critical'/unrecoverable error and what is not?
>
> So: In the real world, be prepared for exceptions anywhere. One thing I've
> learnt from these discussions is that it's impossible to crusade against
> other programmers' preferences. So you've gotta be prepared for anything,
> anytime.
> Sucks, doesn't it. <g>
>
> Kristofer
>
>
>
>
>