Cobol - COBOL and exceptions (was: Passing an invalid date to INTEGER-OF-DATE

Author

COBOL and exceptions (was: Passing an invalid date to INTEGER-OF-DATE

William M. Klein

2005-05-24, 8:55 pm

There was a lot of discussion as to whether or not the '89 Amendment should have
been passed with no method for detecting argument errors. The first draft DID
include returned-values to indicate "problems" - but as some functions could
have invalid arguments but NO returned value was always "invalid" this was
(eventually) rejected.

The '02 Standard (as Chuck indicates) did introduce a "Common Exception
Handling" facility that was intended to provide a "common" solution to ALL of
the exceptions mechanisms previously available - as well as for some things
(like "incompatible data" and invalid arguments) for which NO mechanism
previously existed.

The most controversial part of this proposal (now standard) was whether
detection should be "inline" (IF right after the exception) or out-of-line
(declaratives). The Standard went with the latter *and* provided a "RESUME"
statement that let you restart at a few "selectable" places. This requires
"totally UN-structured" code and is still (at least a little) controversial.

HOWEVER, and this is a BAGGIE !!!!
I know of NO vendor who has actually implemented the '02 Standard "common
exception handling" specification (much less implemented it completely). I have
heard (unofficially) from some vendors that they have ZERO intention of ever
doing so - even if they did everything else in the '02 Standard. At least one
vendor has adopted a C-like "throw/catch" (or whatever C uses) facility.

The good news (related to the initial thread) is that the '02 Standard also
introduced some TEST-xxxx intrinsic functions that allow a programmer to
"validate" arguments for a number of other intrinsic functions and to determine
why they are invalid (if they are). I don't know which vendors (if any) have
implemented these, but I have heard more positive feedback about them - than for
the entire "common exception handling" model.

P.S. For those used to other environments, the Common Exception Handling
facility is similar (not identical to) the PL/I "ON-unit" facility and/or the
(IBM CICS) EXEC CICS HANDLE CONDITION facility.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:d700q2$b7s$1@si05.rsvl.unisys.com...
> I'm not convinced ON ERROR is necessarily the best approach here, or for
> that matter in general, particularly given the ability to "nest" function
> calls.
>
> The '02 standard includes exception handling (for this and in general) in a
> way that, in my opinion, doesn't invalidate existing programs and allows
> their enhancement to catch such problems. Lobby your vendors!
>
> -Chuck Stevens
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:d6vutt$3fp$1@peabody.colorado.edu...
> 20050532
> designed for
> doesn't
> design - as
>
>

Chuck Stevens

2005-05-24, 8:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:mWLke.169630$hh4.32263@fe06.news.easynews.com...

> The good news (related to the initial thread) is that the '02 Standard
also
> introduced some TEST-xxxx intrinsic functions that allow a programmer to
> "validate" arguments for a number of other intrinsic functions and to
determine
> why they are invalid (if they are).

.... and that includes function TEST-DATE-YYYYMMDD, which returns 1 if the
year is out of range, 2 if the month is out of range, 3 if the day of the
month is out of range for the given month and year, and 0 if the date is a
valid YYYYMMDD date. Julian dates are also covered (function
TEST-DAY-YYYYDDD).

-Chuck Stevens

Chuck Stevens

2005-05-27, 3:55 am

Sponsored Links