exception handling

exception handling

[MIXSIM]

Hello people,

I don't think my first request got through, so here it goes again.

Has anybody mastered the art of exception handling??? Are there any
research papers or phd thesis or writing on bathroom walls that has
solved this headache.  I am not real enthused about runtime visibility
of exceptions.

Talk to me!!!!!!!!!!!!!!
                           Thanks,
                             Mike Endrizzi

Exception Handling

[Robbie Gates]

Hi all,
  Just a quick query:
Where did the concept of exception handling originate ? For example,
which languages were first to support this, or which papers first
proposed exception handling ?
  replies by email please, i don't read this group.
- robbie
-- 
----------------------------------------------------------------------
      robbie gates      |
  apprentice algebraist |    http://cat.maths.usyd.edu.au/~robbie
    pgp key available   |

Re: Exception Handling

[Patrick Doyle]

In article <323750EA.167E@maths.usyd.edu.au>,
Robbie Gates  <robbie@maths.usyd.edu.au> wrote:
>Hi all,
>  Just a quick query:
>Where did the concept of exception handling originate ? For example,
>which languages were first to support this, or which papers first
>proposed exception handling ?
>  replies by email please, i don't read this group.
>- robbie

  Ha ha ha!

  Well, if you're not going to bother reading this, I won't bother 
writing it.

 -PD

Re: Exception Handling

[Rick Decker]

Patrick Doyle wrote:
> 
> In article <323750EA.167E@maths.usyd.edu.au>,
> Robbie Gates  <robbie@maths.usyd.edu.au> wrote:
> >Hi all,
> >  Just a quick query:
> >Where did the concept of exception handling originate ? For example,
> >which languages were first to support this, or which papers first
> >proposed exception handling ?
> >  replies by email please, i don't read this group.
> >- robbie
> 
>   Ha ha ha!
> 
>   Well, if you're not going to bother reading this, I won't bother
> writing it.
> 
>  -PD

Robbie,

Perhaps a more felicitous wording might have been "please reply by
email if you don't want to clutter up your group with replies
to my query."  Although opinions differ, it's usually considered
polite when you ask a question of a newsgroup to lurk around for
a few days to see what answers you get.  Though most newsreaders
give the option of an email response, that feature doesn't exist
(or doesn't work) on all, so asking for an email response requires
extra work for some people.

BTW, PL/I is usually credited for first using exceptions, though
rudimentary forms existed as far back as COBOL.

Regards,

Rick

-----------------------------------------------------
Rick Decker                   rdecker@hamilton.edu
Department of Comp. Sci.      315-859-4785
Hamilton College
Clinton, NY  13323            =  !=  ==  (!)
-----------------------------------------------------

Re: Exception Handling

[Larry Kilgallen]

In article <323855BA.5246@hamilton.edu>, Rick Decker <rdecker@hamilton.edu> writes:

> BTW, PL/I is usually credited for first using exceptions, though
> rudimentary forms existed as far back as COBOL.

When the VAX came out in 1978, it had exceptions built into the
instruction set, and handling them had to be built into the
languages (even if in a clunky fashion).

Before there were Bliss-32 and Bliss-16 with comprehensive
exception handling, there were Bliss-36 and Bliss-11 which
may or may not have had support for exception handling.
I was under the impression that Bliss was originated at
Carnegie Mellon University by the person who went on to
found Tartan Labs.

Presuming application-specific stack-based handling of exceptions
was not a new concept introduced with the VAX, one might want to
follow the hardware trail back to see what non-standard language
support was provided. I don't think the original request nor the
clarification of purpose said anything about the support being in
standardized languages, and in fact that would seem to be the
opposite of giving credit to the true originators.

Larry Kilgallen

Re: Exception Handling

[Bryce]

-----BEGIN PGP SIGNED MESSAGE-----

 Robbie Gates  <robbie@maths.usyd.edu.au> wrote:
>Hi all,
>  Just a quick query:
>Where did the concept of exception handling originate ? For example,
>which languages were first to support this, or which papers first
>proposed exception handling ?
>  replies by email please, i don't read this group.


Hm.  University must be in session again.  Are there any other
homework questions you would like me to answer while I'm at it?


:^)


Bryce

\f

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: www.c2.net/~bryce -- 'BAP' Easy-PGP v1.1b2

iQCVAwUBMjgxxfWZSllhfG25AQHSFQQAqnYF9vSl5Fw+q1rzOHOemoY43jpZtuSj
nHhRRyMay+VRFm7VZqQHylPqazZ9BsfFXsbCw7LvE6oF4a/eUSJKW1wyPLipx5p/
Vcbq0hHLA/uD87/X2/ACFPoxy04vAN9vqNkuPx70g0w5Ank/xqFNLeocqAJmBwmt
BqEz/zjpI38=
=byY5
-----END PGP SIGNATURE-----

Re: Exception Handling

[Larry Kilgallen]

In article <519bl1$bta@lace.colorado.edu>, wilcoxb@cs.colorado.edu (Bryce) writes:

>  Robbie Gates  <robbie@maths.usyd.edu.au> wrote:

>>Where did the concept of exception handling originate ? For example,
>>which languages were first to support this, or which papers first
>>proposed exception handling ?
>>  replies by email please, i don't read this group.

With 5 newsgroups getting the post, I can see why not.

> Hm.  University must be in session again.  Are there any other
> homework questions you would like me to answer while I'm at it?

Bryce, the fact that you would be doing somebody's homework for
them should certainly not deter you from providing answers.

The rest of us will understand, however, if you choose not to
provide _correct_ answers :-)

Larry Kilgallen

Re: Exception Handling

[Robbie Gates]

Firstly, an open apology to the people annoyed by my post.  I realise
now it was unecessarily terse, but it didn't seem like a complex
question
nor one needing long discussion.  live & learn.

I (robbie@maths.usyd.edu.au) wrote:
> >>Where did the concept of exception handling originate ? For example,
> >>which languages were first to support this, or which papers first
> >>proposed exception handling ?
> >>  replies by email please, i don't read this group.

Larry Kilgallen wrote:
> With 5 newsgroups getting the post, I can see why not.
Another reason i wanted replies by email, to avoid this sort of
crossposting.  I'm only crossposting this so i can say sorry to
those i've incovenienced.  I do read one of the groups (evidently),
i didn't want to have to track 5 groups for what should have been
an easy answer.

wilcoxb@cs.colorado.edu (Bryce) writes:
> > Hm.  University must be in session again.  Are there any other
> > homework questions you would like me to answer while I'm at it?
Larry Kilgallen wrote:
> Bryce, the fact that you would be doing somebody's homework for
> them should certainly not deter you from providing answers.

For the record, it's not homework, i should have explained more fully.
I'm a pure math phd student, and part of my work provides a nice
model of some parts of programming, in particular exception handling.
i'd like to give proper credit to the originator of the concept, and
will of course acknowledge my sources and the people who helped me
find them.

none of my C++ or Java books actually said where the idea came
from, and so i figured it wasn't common practice in books on programming
to actually say where features originated.  Hence a library search
seemed
pointless with some information to narrow it, hence my post.
judging from my difficulty in finding the answer in places i expected
to find it, a post to several newsgroups on languages i do know support
exception handling didn't seem overkill.

> The rest of us will understand, however, if you choose not to
> provide _correct_ answers :-)
i don't know about you, but i would hardly believe anything i read
on usenet unless i could independently verify the referenced sources.

'nuff said, i'm sorry & i hope y'all understand my position a little
better now.

- robbie

-- 
----------------------------------------------------------------------
      robbie gates      |
  apprentice algebraist |    http://cat.maths.usyd.edu.au/~robbie
    pgp key available   |

Re: Exception Handling

[Paul A. Houle]

Don't sweat it.  People on newsgroups treat each other like
garbage.  This is because we can.  If people talked trash to each
other the way that we do on USENET,  we'd see visual nonverbal
signals of agression that would make us feel to distressed to
continue.

	When the people on the other end of the connection are
nothing more than a bit of badly written,  and these days,  badly
formatted,  text sometimes you get to feel that people should get
the death penalty for stupid posts,  unsolicited commerical spam
and such.

	Another issue is that computer people are not good about
attribution.  To take an example,  it seems clear that the advances
in compiler technology from,  say,  the mid 60's to the mid 80's
sprang from the lingustic discoveries of Noam Chomsky.  Most of the
people who use the technology don't care.  In fact,  even CS
academics don't talk about it much,  probably because they
associate Noam Chomsky with the student protests of the 1960's
and opposition to the Vietnam war.  

	I get the impression that people learn programming from
copying other people's code.  If book publishers were honest about
it,  they'd write a book titled "Learn to Cut and Paste Java in
21 Hours!"  People are more concerned with getting a program
working fast than they are on attributing the source.

Re: Exception Handling

[Rick Decker]

Paul A. Houle wrote:
> 
> Don't sweat it.  People on newsgroups treat each other like
> garbage.  This is because we can.  If people talked trash to each
> other the way that we do on USENET,  we'd see visual nonverbal
> signals of agression 

[like a punch in the mouth, f'r example]

>that would make us feel to distressed to
> continue.
> 
>         When the people on the other end of the connection are
> nothing more than a bit of badly written,  and these days,  badly
> formatted,  text sometimes you get to feel that people should get
> the death penalty for stupid posts,  unsolicited commerical spam
> and such.

Quite right.  One makes allowances for newbie behavior in the hope
that with time will come an understanding of, say, newsgroup netiquette.
What I find far more distressing is having to listen to people
who, after months and perhaps years, never manage to infer the rules
governing polite behavior.  Oh well, that's what killfiles are for, but
it's still regrettable.
> 
>         Another issue is that computer people are not good about
> attribution.  To take an example,  it seems clear that the advances
> in compiler technology from,  say,  the mid 60's to the mid 80's
> sprang from the lingustic discoveries of Noam Chomsky.  Most of the
> people who use the technology don't care.  In fact,  even CS
> academics don't talk about it much,  probably because they
> associate Noam Chomsky with the student protests of the 1960's
> and opposition to the Vietnam war.

Oh, golly.  Now I have to disagree.  First, for someone to choose 
deliberately to ignore Chomsky for his activities against the war would 
require (1) that these activities were known, which would likely mean 
the person would have to be at least as venerable as I am and (2) 
that the person would even find such behavior reprehensible in the first 
place.  No, I'd suggest that the liklier reasons would be that,
first, Chomsky's stuff is somewhat intimidating for a non-specialist, 
and, second, that there are quite a few derivative sources in CS 
literature that put transformational grammars and language hierarchies
in a much more familiar context.  I just did a quick scan of my 
bookshelves and of the sixteen books I have on theory and formal 
languages all sixteen mention Chomsky prominently.  I got bored before I 
finished my compiler texts, but at least the Dragon Book and Son of 
Dragon both contain citations of Chomsky.  Doesn't sound to me that 
he's *that* seriously ignored.
> 
>         I get the impression that people learn programming from
> copying other people's code.

I don't have a problem with that.  My guess is that if you were to ask
a collection of programmers how they learned that particular skill, a 
large fraction would admit to having spent a lot of time looking at the 
code other people produced.  After all, isn't that the way we all 
learned our first (and subsequent) natural language?  So why should 
learning a programming language be that much different?

>If book publishers were honest about
> it,  they'd write a book titled "Learn to Cut and Paste Java in
> 21 Hours!" 

If the title were a truthful statement of the contents, I'd buy it
in a second.  Even better, if I thought it could be done, I'd write
it myself and retire early.  Unfortunately, it's a hopeless task.  Even 
if you used a modern app builder, where the cutting and pasting is done 
by the program, no collection of canned code could possibly cover all 
the apps we would want to write.  The inevitable conclusion is that
no matter how many code exemplars we have available, we still have 
to know enough to wrap them up in a robust, correct program, which
is very good news for those of us in the ed biz.  That said, I'll
still reiterate my point that while on the road to learning how to 
program, examples can be very useful.

>People are more concerned with getting a program
> working fast than they are on attributing the source.

Good.  I get to end on a note of agreement, sort of.  I agree that
the general standards of citation could use some work.  The rules
differ slightly between real world programs and the sort of toy
programs students write, but not by much.  Getting a program working 
fast is a good thing.  Understanding what you're doing is even better,
and acknowledging publicly where the borrowed chunks came from is even 
better.


Regards,

Rick

-----------------------------------------------------
Rick Decker                   rdecker@hamilton.edu
Department of Comp. Sci.      315-859-4785
Hamilton College
Clinton, NY  13323            =  !=  ==  (!)
-----------------------------------------------------

Re: Exception Handling

[Felix Kasza]

Robbie,

 > replies by email please, i don't read this group.

Not feeling very sociable today, are we?

 > Where did the concept of exception handling originate ?

I don't know -- but I do know that IBM's /360 architecture uses a
mechanism for OS calls which looks very much like a trap.  PDPs used
similar features to handle illegal memory references.  In the late 60s
or early 70s, I saw an APL interpreter for the PDP that expressly made
use of this although it didn't export the functionality to the
programmer (APL has no concept of an exception).

Cheers,
Felix.

Re: Exception Handling

[David B. Shapcott [C]]

In article <32393072.72033128@shdgate.shd.de>,
Felix Kasza <felixk@mailbag.shd.de> wrote:
>Robbie,
>
> > replies by email please, i don't read this group.
>
>Not feeling very sociable today, are we?
>
> > Where did the concept of exception handling originate ?
>
>I don't know -- but I do know that IBM's /360 architecture uses a
>mechanism for OS calls which looks very much like a trap.  PDPs used
>similar features to handle illegal memory references.  In the late 60s
>or early 70s, I saw an APL interpreter for the PDP that expressly made
>use of this although it didn't export the functionality to the
>programmer (APL has no concept of an exception).

I've heard that the Babbage Engine had an ingenious exception mechanism
consisting of a cog and spring-loaded trip mechanism, that would activate
a rod releasing a steel ball-brearing down a raceway.  The weight of the
ball bearing was the value of the exception being thrown (for some time,
Babbage had actually considered a throwing arm mechanism, but found that
his mechanism could not be made accurate -- but this does provide an
interesting historical account for the phrase `throwing an exception').


-- 
D. Brad Shapcott [C]
Contractor, Motorola Cellular Infrastructure Group

Re: Exception Handling

[Bart Termorshuizen]

David B. Shapcott [C] wrote:
> 
> In article <32393072.72033128@shdgate.shd.de>,
> Felix Kasza <felixk@mailbag.shd.de> wrote:
> >Robbie,
> >
> > > replies by email please, i don't read this group.
> >
> >Not feeling very sociable today, are we?
> >
> > > Where did the concept of exception handling originate ?
> >
> >I don't know -- but I do know that IBM's /360 architecture uses a
> >mechanism for OS calls which looks very much like a trap.  PDPs used
> >similar features to handle illegal memory references.  In the late 60s
> >or early 70s, I saw an APL interpreter for the PDP that expressly made
> >use of this although it didn't export the functionality to the
> >programmer (APL has no concept of an exception).
> 
> I've heard that the Babbage Engine had an ingenious exception mechanism
> consisting of a cog and spring-loaded trip mechanism, that would activate
> a rod releasing a steel ball-brearing down a raceway.  The weight of the
> ball bearing was the value of the exception being thrown (for some time,
> Babbage had actually considered a throwing arm mechanism, but found that
> his mechanism could not be made accurate -- but this does provide an
> interesting historical account for the phrase `throwing an exception').
> 
> --
> D. Brad Shapcott [C]
> Contractor, Motorola Cellular Infrastructure Group

Way to go!  ;)
Bart.

Re: Exception Handling

[Norman H. Cohen]

In article <323750EA.167E@maths.usyd.edu.au>, Robbie Gates
<robbie@maths.usyd.edu.au> writes: 

|> Where did the concept of exception handling originate ? For example,
|> which languages were first to support this, or which papers first
|> proposed exception handling ?

A good early survey of exception handling can be found in: 

   Goodenough, John B.  Exception handling:  issues and a proposed
   notation.   Communications of the ACM 18, No. 12 (December 1975),
   pp. 683-696

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Exception Handling

[Robin Vowels]

	ncohen@watson.ibm.com (Norman H. Cohen) writes:

	>In article <323750EA.167E@maths.usyd.edu.au>, Robbie Gates
	><robbie@maths.usyd.edu.au> writes: 

	>|> Where did the concept of exception handling originate ? For example,
	>|> which languages were first to support this, or which papers first
	>|> proposed exception handling ?

The IBM System 360 (c. 1965) had an interrupt system that could
trap a range of computational conditions (division by
zero, floating-point overflow, fixed-point overflow,
floating-point underflow, loss of signficance, etc.
Such exceptions could be trapped by the OS, and a few
could be trapped by the user.  Such things
as protection exceptions were trapped by the OS.

Operating system service was initiated with an interrupt
generated by a user instruction SVC (SVC = SuperVisor Call).

THe S/360 probably extended the idea considerably over
what had appeared before.

Before that (c. 1961), the Burroughs B series would have
had protection and array subscript bound checking and whatever
else.  Perhaps someone can add something for that or other systems....

Re: Exception Handling

[Bob Halpern]

Robin Vowels wrote:
 
>         >|> Where did the concept of exception handling originate ? For example,
>         >|> which languages were first to support this, or which papers first
>         >|> proposed exception handling ?
> 
> The IBM System 360 (c. 1965) had an interrupt system that could
> trap a range of computational conditions (division by

There was hardware and software for exception handling that predated the
360.

The 7740 communications processor had several levels of interrupt
(exactly like
a PSW), had vectors to tell the software what happened (exactly like a
CSW),
additional PSWs for low storage, errors, etc.

Re: Exception Handling

[Fritz Schneider]

Bob Halpern <wumpus@ix.netcom.com> wrote:

>Robin Vowels wrote:
> 
>>         >|> Where did the concept of exception handling originate ? For example,
>>         >|> which languages were first to support this, or which papers first
>>         >|> proposed exception handling ?
>> 
>> The IBM System 360 (c. 1965) had an interrupt system that could
>> trap a range of computational conditions (division by
>
>There was hardware and software for exception handling that predated the
>360.
>

The IBM 709 (a vacuum tube machine) introduced the concept of data
channels (now called DMA) in a commercial product ca. 1957. This
included interruptions, referred to in that architecture as traps. The
current instruction address was stored in a fixed location and control
was given to the channel trap routine which stored the registers and
processed the interruption. The instruction set included the TTR (TRAP
TRANSFER) instruction used to return from interruptions. It could not
be trapped, so the next interruption would occur back in the user
program rather than in the trap routine.
Fritz Schneider
Peacham Cybernetics
Sunnyvale, California
http://www.Peacham.com/~fritz/

Re: Exception Handling

[Robin Vowels]

	Fritz@Peacham.com (Fritz Schneider) writes:

	>Bob Halpern <wumpus@ix.netcom.com> wrote:
	>>Robin Vowels wrote:
	>>>         >|> Where did the concept of exception handling originate ? For example,
	>>>         >|> which languages were first to support this, or which papers first
	>>>         >|> proposed exception handling ?
	>>> 
	>>> The IBM System 360 (c. 1965) had an interrupt system that could
	>>> trap a range of computational conditions (division by
	>>
	>>There was hardware and software for exception handling that predated the
	>>360.

	>The IBM 709 (a vacuum tube machine) introduced the concept of data
	>channels (now called DMA) in a commercial product ca. 1957. This
	>included interruptions, referred to in that architecture as traps. The
	>current instruction address was stored in a fixed location and control
	>was given to the channel trap routine which stored the registers and
	>processed the interruption. The instruction set included the TTR (TRAP
	>TRANSFER) instruction used to return from interruptions. It could not
	>be trapped, so the next interruption would occur back in the user
	>program rather than in the trap routine.
	>Fritz Schneider >Peacham Cybernetics >Sunnyvale, California

Thanks for that info.

As far as DMA goes, the English Electric DEUCE computer
(c. 1955) performed asynchronous transfer between drum and
main memory.  I think that the ACE computer (c. 1950) did also.

Re: Exception Handling

[shmuel]

In <32529a13.6465307@nntp.netgate.net>, Fritz@Peacham.com (Fritz Schneider) writes:
>Bob Halpern <wumpus@ix.netcom.com> wrote:
>
>The IBM 709 (a vacuum tube machine) introduced the concept of data
>channels (now called DMA) in a commercial product ca. 1957. 

Sorry, but the data-channel trap feature of the 709 was not the first either. 
The earliest reference that I've seen to interrupts was on the 1103A, but I 
wouldn't put any money on it being first.

Re: Exception Handling

[Bob Halpern]

shmuel@os2bbs.com wrote:
> 
> In <32529a13.6465307@nntp.netgate.net>, Fritz@Peacham.com (Fritz Schneider) writes:
> >Bob Halpern <wumpus@ix.netcom.com> wrote:
> >
> >The IBM 709 (a vacuum tube machine) introduced the concept of data
> >channels (now called DMA) in a commercial product ca. 1957.
> 
> Sorry, but the data-channel trap feature of the 709 was not the first either.
> The earliest reference that I've seen to interrupts was on the 1103A, but I
> wouldn't put any money on it being first.

The SWAC had branching on overflow, negative, in the instruction. It
was built in the mid 50s, before the 709x, before the 650, before the
1103A (fine machine - shame Univac didn't realize it).

Re: Exception Handling

[Thiago]

Robin Vowels wrote:
> 
>         ncohen@watson.ibm.com (Norman H. Cohen) writes:
> 
>         >In article <323750EA.167E@maths.usyd.edu.au>, Robbie Gates
>         ><robbie@maths.usyd.edu.au> writes:
> 
>         >|> Where did the concept of exception handling originate ? For example,
>         >|> which languages were first to support this, or which papers first
>         >|> proposed exception handling ?
> 
> The IBM System 360 (c. 1965) had an interrupt system that could
> trap a range of computational conditions (division by
> zero, floating-point overflow, fixed-point overflow,
> floating-point underflow, loss of signficance, etc.
> Such exceptions could be trapped by the OS, and a few
> could be trapped by the user.  Such things
> as protection exceptions were trapped by the OS.
> 
> Operating system service was initiated with an interrupt
> generated by a user instruction SVC (SVC = SuperVisor Call).
> 
> THe S/360 probably extended the idea considerably over
> what had appeared before.
> 
> Before that (c. 1961), the Burroughs B series would have
> had protection and array subscript bound checking and whatever
> else.  Perhaps someone can add something for that or other systems..UFMA - Brasil
Here the Java programming language are not an usual one. We use usually C++, VB, 
CLIPPER and DELPHI.

Re: Exception Handling

[Marin David Condic, 407.796.8997, M/S 731-93]

Felix Kasza <felixk@MAILBAG.SHD.DE> writes:
>I don't know -- but I do know that IBM's /360 architecture uses a
>mechanism for OS calls which looks very much like a trap.  PDPs used
>similar features to handle illegal memory references.  In the late 60s
>or early 70s, I saw an APL interpreter for the PDP that expressly made
>use of this although it didn't export the functionality to the
>programmer (APL has no concept of an exception).
>
    Well, if we include "hardware" in the picture, you'd have to go
    back to the very first invention of an interrupt. Assemblers, of
    course, let you write an interrupt handler and in that sense had
    "exception processing."

    When did it get incorporated in computer languages? That requires
    an answer to the question: "What exactly do you mean by 'exception
    processing'?" "Asynchronous transfer of control when an error is
    detected by the hardware or the programmer" would allow any
    language which gave you the ability to write an interrupt service
    routine and/or write a software triggered interrupt to qualify.
    That's most of them - except since this was always hardware
    dependent, it was probably not done as part of any "language
    standard" (more likely a vendor supplied utility).

    If we mean "programmer triggered exceptions" then we'd have to
    look to all the languages which provided some kind of syntax
    similar to: "ON ERROR THEN GOTO XXXX" - which would include quite
    a few very antiquated languages.

    If we mean "language triggered exceptions" (runtime checks
    inserted by the language translator and unseen by the programmer
    which may or may not include various hardware interrupts or
    exceptions which transfer control to a programmer specified chunk
    of code) then I *think* that Ada83 pretty much invented it. I am
    reasonably fluent in Fortran, Cobol, Pascal, C, and Ada and I have
    a passing knowlege of a number of more obscure languages like
    Lisp, Snobol, RPG, etc., and Ada was the first language I've ever
    encountered which included something in its syntax which meets
    this definition.

    I encountered Ada in the late '70s and discovered the exception
    handler at that point. One could check the Rationale for Ada 83
    and some of its early design documents which would give clues as
    to where the language designers derived their ideas. The
    brain-cell I dedicated to those events reminds me that the
    designers looked at many other languages and didn't find
    "adequate" features to cover a number of requirements such as
    tasking, exception handling, etc. That would be a hint, but I
    don't trust that brain-cell much these days.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
   "Don't say yes until I finish talking."

        -- Darryl F. Zanuck
===============================================================================

Re: Exception Handling

[Larry Kilgallen]

In article <96091317002428@psavax.pwfl.com>, "Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:

>     If we mean "language triggered exceptions" (runtime checks
>     inserted by the language translator and unseen by the programmer
>     which may or may not include various hardware interrupts or
>     exceptions which transfer control to a programmer specified chunk
>     of code) then I *think* that Ada83 pretty much invented it. I am
>     reasonably fluent in Fortran, Cobol, Pascal, C, and Ada and I have
>     a passing knowlege of a number of more obscure languages like
>     Lisp, Snobol, RPG, etc., and Ada was the first language I've ever
>     encountered which included something in its syntax which meets
>     this definition.

DEC Pascal triggers exceptions when constraints are violated, and
catching them is done in a vendor-specific manner.  I would assume
the discussion is not limited to standard-based implementations,
because then we would not be talking about who originate the concept
but rather whose committee was quickest to adopt research.

V1 of DEC Pascal, however, was from a different codebase than the V5.?
currently shipping.i

Larry Kilgallen

Re: Exception Handling

[Robin Vowels]

	"Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:

	>Felix Kasza <felixk@MAILBAG.SHD.DE> writes:
	>>I don't know -- but I do know that IBM's /360 architecture uses a
	>>mechanism for OS calls which looks very much like a trap.  PDPs used
	>>similar features to handle illegal memory references.  In the late 60s
	>>or early 70s, I saw an APL interpreter for the PDP that expressly made
	>>use of this although it didn't export the functionality to the
	>>programmer (APL has no concept of an exception).
	>>
	>    Well, if we include "hardware" in the picture, you'd have to go
	>    back to the very first invention of an interrupt. Assemblers, of
	>    course, let you write an interrupt handler and in that sense had
	>    "exception processing."

	>    When did it get incorporated in computer languages? That requires
	>    an answer to the question: "What exactly do you mean by 'exception
	>    processing'?" "Asynchronous transfer of control when an error is
	>    detected by the hardware or the programmer" would allow any
	>    language which gave you the ability to write an interrupt service
	>    routine and/or write a software triggered interrupt to qualify.
	>    That's most of them - except since this was always hardware
	>    dependent, it was probably not done as part of any "language
	>    standard" (more likely a vendor supplied utility).

	>    If we mean "programmer triggered exceptions" then we'd have to
	>    look to all the languages which provided some kind of syntax
	>    similar to: "ON ERROR THEN GOTO XXXX" - which would include quite
	>    a few very antiquated languages.

	>    If we mean "language triggered exceptions" (runtime checks
	>    inserted by the language translator and unseen by the programmer
	>    which may or may not include various hardware interrupts or
	>    exceptions which transfer control to a programmer specified chunk
	>    of code) then I *think* that Ada83 pretty much invented it.

Certainly one of the earliest -- if not *the* earliest -- was
PL/I, which in 1966 introduced exception handling for a wide
range of machine and programmer-defined exceptions.

OTOMH, they included 
   fixed-point overflow, floating-point overflow, floating-point
underflow, subscriptrange (for subscript errors), stringrange
(for substring errors), division by zero, size, endpage (for
handling end-of-page exceptions), endfile (for end-of-file),
data conversion errors, various file exceptions,
as well as the programmer-defined exceptions.  There was also
a facility for handling errors of a general nature (ERROR),
and even one for handling the end-of-job (FINISH).

   For data conversion errors, built-in functions enabled
access to the erroneous data fields, and corresponding
pseudo variables enabled the erroneous data to be
replaced with legitimate data, and the conversion re-attempted
if reqquired.

   These facilities are still in PL/I, and -- of course --
have been enhanced over the years.

	>    I am
	>    reasonably fluent in Fortran, Cobol, Pascal, C, and Ada and I have
	>    a passing knowlege of a number of more obscure languages like
	>    Lisp, Snobol, RPG, etc., and Ada was the first language I've ever
	>    encountered which included something in its syntax which meets
	>    this definition.

Re: Exception Handling

[John Goodenough]

In article <3238B024.794B@maths.usyd.edu.au>, Robbie Gates writes:

|> > >>Where did the concept of exception handling originate ? For example,
|> > >>which languages were first to support this, or which papers first
|> > >>proposed exception handling ?

I believe the first paper to propose the use of the term and to give a
comprehensive discussion of the concept was, well, the following:

    Goodenough, J. B. Exception handling: issues and a proposed notation. CACM
    17, 12 (Dec. 1975), 683-696.

which was based on a paper and presentation given at the Second ACM Symposium
on Principles of Programming Languages in January 1975.  PL/I was the first
widely used language to support exception conditions (called ON conditions),
so someone on the PL/I design team deserves credit for giving high level
language support to the concept.  The notion itself is supported by a variety
of other language mechanisms, as is discussed in the above paper.

There have subsequently been a number of papers and theses on the concept.

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

Re: Exception Handling

[Marin David Condic, 407.796.8997, M/S 731-93]

Larry Kilgallen <kilgallen@EISNER.DECUS.ORG> writes:
>DEC Pascal triggers exceptions when constraints are violated, and
>catching them is done in a vendor-specific manner.  I would assume
>the discussion is not limited to standard-based implementations,
>because then we would not be talking about who originate the concept
>but rather whose committee was quickest to adopt research.
>
    I've long admired the quality of DEC compilers ever since using
    their Fortran-10 on the PDP-10. I have two questions: 1) At what
    point in time did they extend "standard" Pascal with some form of
    exception processing? 2) Could you show a "simple" example of how
    a user might raise & handle the exception? Thanks.

    MDC
Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
   "Don't say yes until I finish talking."

        -- Darryl F. Zanuck
===============================================================================

Re: Exception Handling

[Larry Kilgallen]

In article <96091718200832@psavax.pwfl.com>, "Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:
> Larry Kilgallen <kilgallen@EISNER.DECUS.ORG> writes:
>>DEC Pascal triggers exceptions when constraints are violated, and
>>catching them is done in a vendor-specific manner.  I would assume
>>the discussion is not limited to standard-based implementations,
>>because then we would not be talking about who originate the concept
>>but rather whose committee was quickest to adopt research.
>>
>     I've long admired the quality of DEC compilers ever since using
>     their Fortran-10 on the PDP-10. I have two questions: 1) At what
>     point in time did they extend "standard" Pascal with some form of
>     exception processing? 2) Could you show a "simple" example of how
>     a user might raise & handle the exception? Thanks.

From the start the VMS operating system had exceptions built into
the stack frames, so DEC Pascal V1 (1979 or so ?) users could
force establishment of their own handler by calling the VMS
routine LIB$ESTABLISH.  When DEC Pascal V2 arrived (1982 ?)
it was a total rewrite and required use of a specific language
extension to establish programmer-specified handlers since the
same OS mechanism was also used for language-specified handlers
pertaining to the chaining for uplevel addressing as I recall.

The following code has not been run through a compiler, and
leaves out some of the attributes required for safe programming.
The compiler would surely complain, but the is probably more
clear than the version the compiler would accept:

	PROCEDURE MY_PROCEDURE;

	FUNCTION MY_HANDLER ( SIGVEC : SIGVEC_TYPE;
				 MECHVEC : MECHVEC_TYPE ) : INTEGER;
		BEGIN

		IF SIGVEC [1] = MY_EXCEPTION_VALUE
		THEN
			MY_HANDLER := SS$_CONTINUE
		ELSE
			MY_HANDLER := SS$_RESIGNAL;
		END;
	BEGIN

	ESTABLISH ( MY_HANDLER );

	LIB$SIGNAL ( MY_EXCEPTION_VALUE );

	END;

Larry Kilgallen

Re: Exception Handling

[Robert Dewar]

Bob Halpern said

"There was hardware and software for exception handling that predated the
360."

Yes indeed, the KDF9 had a particularly nice interrupt system. You could
issue a tape read to a block of memory. There was no end of transfer
interrupt BUT if you attempted to read from the block of memory before
the transfer was complete THEN you got an interrupt. This is a nicer
arrangement than we see in current day hardware!

Exception Handling

[NANCY HEHIR]

The Ada language reference manual (chapter 11) indicates that when an
exception is raised the main body of code is abandoned and that if code
exists for handling the exception then this is executed.

Is it possible to use the exception handler to return to the main body at a
point before the point where the exception is raised?

For example: If I prompt for a keyboard input of ,say an eight character
string, and a seven char string is actually inputted, a Constraint_Error is
raised. Can I use a handling device to return the execution to the prompt
for input ?

Re: Exception Handling

[Preben Randhol]

On Mon, 29 May 2000 23:53:18 +0100, NANCY HEHIR wrote:
>The Ada language reference manual (chapter 11) indicates that when an
>exception is raised the main body of code is abandoned and that if code
>exists for handling the exception then this is executed.
>
>Is it possible to use the exception handler to return to the main body at a
>point before the point where the exception is raised?
>
>For example: If I prompt for a keyboard input of ,say an eight character
>string, and a seven char string is actually inputted, a Constraint_Error is
>raised. Can I use a handling device to return the execution to the prompt
>for input ?

Yes by using a loop around a begin exception end block. 

This is from the top of my head so it might not work without
modifications:

   loop
      begin    -- This is the start of the block
         read_from_keyboard;
         exit; -- The code won't reach here if Constraint_Error is
               -- raised by the previous function.
      exception
         when E : Constraint_Error =>
         Put_Line("Wrong input, try again!");
      end;
   end loop;

Note it might increase readability a bit if you did something like this
(I'm not sure):

   correct_input : boolean := false;
   
   [...]

   loop
      begin    -- This is the start of the block
         read_from_keyboard;
         correct_input := true;
      exception
         when E : Constraint_Error =>
         Put_Line("Wrong input, try again!");
      end;
      exit when correct_input;
   end loop;


Also note that you can use :

   Input_String : String(1..30);
   Length       : Natural := 0;

   [...]
   
      Ada.Text_IO.Get_Line(Item => Input_String, Last => Length);

   then you can use:

      Input_String(1..Length)

I would recommend that you read the "Ada 95 Problem Solving and Program
Design", 3rd ed. by Feldman and Koffman. For a nice introduction to Ada.
More info can be found here:
http://www.seas.gwu.edu/faculty/mfeldman/cs1book

-- 
Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/>
         "Det eneste trygge stedet i verden er inne i en fortelling."
                                                      -- Athol Fugard

Re: Exception Handling

[Jeffrey D. Cherry]

NANCY HEHIR wrote:
> 
> For example: If I prompt for a keyboard input of ,say an eight character
> string, and a seven char string is actually inputted, a Constraint_Error is
> raised. Can I use a handling device to return the execution to the prompt
> for input ?

Preben Randhol had a good response to this but I would like to add my 2 cents.
You could use an exception handler to trap this kind of input error but I 
prefer to use exceptions for things that are a bit more unexpected.  (Please 
note that this is a personal bias.)  Invalid input is what I would call an 
expected error, so I apply validation criteria to the input before accepting 
it.  In your example, the only criteria is that the string be 8 characters 
in length, so I would make this an explicit test.  Making an explicit test 
shows the reader of the software what I'm looking for in order to accept the
input as valid.  Depending on an exception handler to perform validation 
obscures this message.  However, to be fair, there are cases where trapping
an exception is the better method.  Clarity of the source code in expressing 
the intent should be the discriminator for whichever method is ultimately 
used.  And so, with that disclaimer, here is my suggestion ...

Following, is a function that returns an eight character string read from 
standard input.  This function assumes standard output is available for prompts 
and error messages.  I prefer using Get_Line to read strings from standard 
input but other methods may be used as well.  (A "with" and "use" of 
Ada.Text_IO is assumed.)  Note the input buffer variable should be set to some
"reasonable" length.  Its intent is to hold the largest input line entered from 
standard input.  Arbitrarily I chose a length of 512 characters.

function Get_8_Char_String return string is
   -- A lower bound of 1 for the input buffer was chosen for ease of testing 
   -- in the function body.
   Buffer : string(1..512);
   Last   : natural;
begin -- Get_8_Char_String
   loop
      Put("Please enter an 8 character string: ");
      Get_Line(Buffer, Last);
      exit when Last = 8;
      New_Line;
      Put_Line("Input error, input must be 8 characters.");
      New_Line;
   end loop;
   return Buffer(1..Last);
end Get_8_Char_String;

-- 
Regards,
Jeffrey D. Cherry
Senior IV&V Analyst
Logicon Space and Information Operations
Logicon Inc.
a Northrop Grumman company

Re: Exception Handling

[Gautier]

BTW, checking a string length via exception is not safe because
of pragma suppress(range_check) ...
______________________________________________________
Gautier  --  http://members.xoom.com/gdemont/gsoft.htm

Re: Exception Handling

[Robert Dewar]

In article <3933F599.A15E55BC@maths.unine.ch>,
  Gautier <gautier.demontmollin@maths.unine.ch> wrote:
> BTW, checking a string length via exception is not safe
because
> of pragma suppress(range_check) ...


Note that this is why GNAT provides Unsuppress. The ARG
is currently discussing semi-standarization of this pragma.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Exception Handling

[Preben Randhol]

On Tue, 30 May 2000 08:14:59 -0700, Jeffrey D. Cherry wrote:

>Preben Randhol had a good response to this but I would like to add my 2 cents.
>You could use an exception handler to trap this kind of input error but I 
>prefer to use exceptions for things that are a bit more unexpected.  (Please 
>note that this is a personal bias.)  Invalid input is what I would call an 
>expected error, so I apply validation criteria to the input before accepting 
>it.  In your example, the only criteria is that the string be 8 characters 

In this example I agree with you. 

One slightly different angle though. Say you have made a program that
expects the user to input a value. It could be any value so it should be
possible to enter 2.3E-4 etc...

Would it be OK to trap an erronious entry (like "2.3W-4") with an
exception or would you make an extra check before trying to convert the
string to a float (or the appropriate class).

The reason I'm asking is that there seems to be two "camps" those who
use exceptions extensivly and those who use it far less. I'm trying to
find the border when and when not to use exceptions.

-- 
Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/>
         "Det eneste trygge stedet i verden er inne i en fortelling."
                                                      -- Athol Fugard

Re: Exception Handling

[Jeff Carter]

Preben Randhol wrote:
> One slightly different angle though. Say you have made a program that
> expects the user to input a value. It could be any value so it should be
> possible to enter 2.3E-4 etc...
> 
> Would it be OK to trap an erronious entry (like "2.3W-4") with an
> exception or would you make an extra check before trying to convert the
> string to a float (or the appropriate class).

Ada provides at least 2 ways to check that a string contains an
appropriate representation of a floating-point number: 'Value and
Ada.Text_IO.Float_IO. Both convert the string to a floating-point value
and signal an invalid string by raising an exception. Whether you agree
that raising an exception is appropriate, why would you write another
subprogram to parse a string for a floating-point value when you can
reuse these existing, robust, and well-tested subprograms?

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: Exception Handling

[Preben Randhol]

On Thu, 01 Jun 2000 23:31:06 GMT, Jeff Carter wrote:

>and signal an invalid string by raising an exception. Whether you agree
>that raising an exception is appropriate, why would you write another
>subprogram to parse a string for a floating-point value when you can
>reuse these existing, robust, and well-tested subprograms?

I agree with you.

I guess one can draw from the answers (thanks all) that one should not
use exceptions to guide the flow of the program when one can use an if
instead.

-- 
Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/>
         "Det eneste trygge stedet i verden er inne i en fortelling."
                                                      -- Athol Fugard

Re: Exception Handling

[Jeffrey D. Cherry]

Jeff Carter wrote:
> 
> Ada provides at least 2 ways to check that a string contains an
> appropriate representation of a floating-point number: 'Value and
> Ada.Text_IO.Float_IO. Both convert the string to a floating-point value
> and signal an invalid string by raising an exception. Whether you agree
> that raising an exception is appropriate, why would you write another
> subprogram to parse a string for a floating-point value when you can
> reuse these existing, robust, and well-tested subprograms?

Normally you would always use the available facilities to perform this kind 
of an operation.  There are, however, rare situations where the Ada library 
facilities are not available.  One example would be when developing an 
embedded application.  The compiler vendor does not always supply a run-time 
library for the target processor.  Another example would be a in a 
safety-critical application that requires certification of all the code, 
including the run-time library routines.  In these cases, some compiler 
vendors don't supply the source for their run-time libraries, or it's too 
expensive to get a certified version of the run-time library and so the 
developer generates equivalent versions of the few run-time library routine 
they use in their application.  (I must say that I've never experienced this 
situation with _Ada_ compiler vendors.)

Bear in mind that these two examples have little or no bearing on the original 
example problem which read a string from standard input and converted it to
a float value if there were no format errors on the input string.

-- 
Regards,
Jeffrey D. Cherry
Senior IV&V Analyst
Logicon Space and Information Operations
Logicon Inc.
a Northrop Grumman company

Re: Exception Handling

[Ehud Lamm]

On 1 Jun 2000, Preben Randhol wrote:

|Would it be OK to trap an erronious entry (like "2.3W-4") with an
|exception or would you make an extra check before trying to convert the
|string to a float (or the appropriate class).
|
|The reason I'm asking is that there seems to be two "camps" those who
|use exceptions extensivly and those who use it far less. I'm trying to
|find the border when and when not to use exceptions.
|

The way I see it, it's like this. I try not to use exceptions to guide the
flow inside a routine (like "goto") unless there is a good reason to do so
(e..g, if there is convergence with an exception raised by a service
routine etc.).

So if I am doing a translation myself (char by char) I'd probably use an
"if" (though I am not 100% sue, since you should always check the
complexity things add to your code. If it is simply if s(i) is digits ...
elsif upcase(s(i))='E' ... else ERROR than I can live with that).
If I can use another routine to do the conversion, I'd assume the routine
would communicate the presence of an error with an exception.

Since I assume the input routine is an input routine, and thus wrog input
is problematic, I'd think the input routine itself RAISES an exception.
(This is the other side of the coin...)

You can see an possible approach to these issues (though not exactly
matching your scenario) in my Safe_Io package, and my Generic_Menu
routine. Both on AdaPower.

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: Exception Handling

[Jeffrey D. Cherry]

Preben Randhol wrote:
> 
> Would it be OK to trap an erronious entry (like "2.3W-4") with an
> exception or would you make an extra check before trying to convert the
> string to a float (or the appropriate class).
> 

This, in my opinion, is one of those cases where it is better to trap an 
exception than code a specific routine to parse floating point numbers.  
However, I would use something like Ada.Float_Text_IO (for the standard float
type) or an appropriate instance of Ada.Text_IO.Float_IO to attempt the 
conversion using: 
  procedure Get(From : in String; Item : out Num; Last : out Positive);
In this case I would read the input string, extract the delimited string that
should contain the floating point number, and then use that slice in the 
call to Get.  To trap the exception, I would use either a block statement or 
create a special subprogram like the following:

procedure Get_Float(St : in string; Value : out float; Is_Valid : out boolean)
is
   Last : positive;
begin -- Get_Float
   Ada.Float_Text_IO.Get(St, Value, Last);
   Is_Valid := true;
exception
   when others =>
      Is_Valid := false;
end Get_Float;

The drawback here is that I have no specific information regarding what was 
wrong with the input.  The good thing is that I don't have to write a lengthy
subprogram to parse the floating point number and this provides the readability
that I'm seeking.  It also uses the exception Data_Error if there is something 
wrong with the input format or the input could not be converted to the 
type float.  This avoids the problem of a suppressed constraint check, which 
some compilers use as the default.

There are situations where I would want to write a validation routine that
does not depend on the standard library I/O packages.  One obvious example 
would be an application targeted for an embedded computer.  In these cases, 
the Ada run-time library (such as Text_IO and its children) are very limited
or not available.  In this case I would write my own validation subprogram 
to parse the input string; probably something like a small finite state 
machine.  Of course, I'm moving off our original example here since we assumed 
that I/O was available through standard input and standard output, and we're
validating input from a user-input string.  But you get the idea of the 
situations where I would and would not use an exception to validate input.

-- 
Regards,
Jeffrey D. Cherry
Senior IV&V Analyst
Logicon Space and Information Operations
Logicon Inc.
a Northrop Grumman company

Re: Exception Handling

[David C. Hoos, Sr.]

I'm curious as to why you wouldn't simply use the 'Value
attribute of the specific type to attempt the conversion.
This avoids the expense of an instance of Text_IO.Float_IO
which might be needed for no other purpose, and makes use
of the compiler vendor's parsing routine.
If an exception were raised, the offending string could
be displayed -- e.g:

The_Value : Some_Float_Type;
The_Input_String : String (1 .. 80)
Last : Natural
.
.
.
loop
   Ada.Text_IO.Get_Line (The_Input_String, Last);
   begin
      The_Value := Some_Float_Type'Value (The_String (1 .. Last);
      exit;  -- Will exit if conversion succeeds
   exception
      when E: others =>
         Ada.Text_IO.Put
            ("Invalid input """ &
             The_Input_String (1 .. Last) &
             """; try again.");
   end;
end loop;
-- Use The_Value


Jeffrey D. Cherry <jdcherry@utech.net> wrote in message
news:393677C0.E1A2457F@utech.net...
> Preben Randhol wrote:
> >
> > Would it be OK to trap an erronious entry (like "2.3W-4") with an
> > exception or would you make an extra check before trying to convert the
> > string to a float (or the appropriate class).
> >
>
> This, in my opinion, is one of those cases where it is better to trap an
> exception than code a specific routine to parse floating point numbers.
> However, I would use something like Ada.Float_Text_IO (for the standard
float
> type) or an appropriate instance of Ada.Text_IO.Float_IO to attempt the
> conversion using:
>   procedure Get(From : in String; Item : out Num; Last : out Positive);
> In this case I would read the input string, extract the delimited string
that
> should contain the floating point number, and then use that slice in the
> call to Get.  To trap the exception, I would use either a block statement
or
> create a special subprogram like the following:
>
> procedure Get_Float(St : in string; Value : out float; Is_Valid : out
boolean)
> is
>    Last : positive;
> begin -- Get_Float
>    Ada.Float_Text_IO.Get(St, Value, Last);
>    Is_Valid := true;
> exception
>    when others =>
>       Is_Valid := false;
> end Get_Float;
>
> The drawback here is that I have no specific information regarding what
was
> wrong with the input.  The good thing is that I don't have to write a
lengthy
> subprogram to parse the floating point number and this provides the
readability
> that I'm seeking.  It also uses the exception Data_Error if there is
something
> wrong with the input format or the input could not be converted to the
> type float.  This avoids the problem of a suppressed constraint check,
which
> some compilers use as the default.
>
> There are situations where I would want to write a validation routine that
> does not depend on the standard library I/O packages.  One obvious example
> would be an application targeted for an embedded computer.  In these
cases,
> the Ada run-time library (such as Text_IO and its children) are very
limited
> or not available.  In this case I would write my own validation subprogram
> to parse the input string; probably something like a small finite state
> machine.  Of course, I'm moving off our original example here since we
assumed
> that I/O was available through standard input and standard output, and
we're
> validating input from a user-input string.  But you get the idea of the
> situations where I would and would not use an exception to validate input.
>
> --
> Regards,
> Jeffrey D. Cherry
> Senior IV&V Analyst
> Logicon Space and Information Operations
> Logicon Inc.
> a Northrop Grumman company
>

Re: Exception Handling

[Jeffrey D. Cherry]

"David C. Hoos, Sr." wrote:
> 
> I'm curious as to why you wouldn't simply use the 'Value
> attribute of the specific type to attempt the conversion.
> This avoids the expense of an instance of Text_IO.Float_IO
> which might be needed for no other purpose, and makes use
> of the compiler vendor's parsing routine.

The reason is that the 'Value attribute raises Constraint_Error if there is 
something wrong with the syntax of the input string while the Get procedure
from Ada.Float_Text_IO raises Data_Error.  Constraint_Error can be suppressed 
while Data_Error cannot.

One other thing, while I was looking at the Get_Float procedure I posted I 
noticed an error.  The assignment statement following the call to Get is
incorrect.  The corrected procedure is:

procedure Get_Float(St : in string; Value : out float; Is_Valid : out boolean)
is
   Last : positive;
begin -- Get_Float
   Ada.Float_Text_IO.Get(St, Value, Last);
   Is_Valid := Last = St'last;
exception
   when others =>
      Is_Valid := false;
end Get_Float;

The reason the previous version was wrong is that parameter Last will contain
the index of the last character read during the conversion.  For the example 
string of "2.3W-4", Last would be set to 3, Is_Valid would have erroneously 
been set to true, and Value would be 2.3 rather than 0.00023.  In the corrected
version (above), Is_Valid is set to true only if the entire input string is 
consumed during the conversion.

-- 
Regards,
Jeffrey D. Cherry
Senior IV&V Analyst
Logicon Space and Information Operations
Logicon Inc.
a Northrop Grumman company

Re: Exception Handling

[Preben Randhol]

On 1 Jun 2000 09:57:36 GMT, Preben Randhol wrote:

>Would it be OK to trap an erronious entry (like "2.3W-4") with an
>exception or would you make an extra check before trying to convert the
>string to a float (or the appropriate class).
                                       ^^^^^
                                       ARG!! I really must get some more
                                       sleep. I mean type, not class.

-- 
Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/>
         "Det eneste trygge stedet i verden er inne i en fortelling."
                                                      -- Athol Fugard

RE: Exception Handling

[Antonio Dur�n Dom�nguez]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

I don't think that using an exception as an inconditional break is a good
practice. There are
better ways to achive that effect.

NANCY HEHIR <nanceh.ennis@tinet.ie> escribi� en el mensaje de noticias
3HCY4.29157$sB3.10828@news.indigo.ie...
> The Ada language reference manual (chapter 11) indicates that when an
> exception is raised the main body of code is abandoned and that if code
> exists for handling the exception then this is executed.
>
> Is it possible to use the exception handler to return to the main body at
a
> point before the point where the exception is raised?
>
> For example: If I prompt for a keyboard input of ,say an eight character
> string, and a seven char string is actually inputted, a Constraint_Error
is
> raised. Can I use a handling device to return the execution to the prompt
> for input ?
>
>

Re: Exception Handling

[Robert Dewar]

In article <3HCY4.29157$sB3.10828@news.indigo.ie>,
  "NANCY HEHIR" <nanceh.ennis@tinet.ie> wrote:
> Is it possible to use the exception handler to return to the
> main body at a
> point before the point where the exception is raised?

No. And this is a very deliberate part of the design

> For example: If I prompt for a keyboard input of ,say an eight
character
> string, and a seven char string is actually inputted, a
Constraint_Error is
> raised. Can I use a handling device to return the execution to
the prompt
> for input ?

You can easily program this effect with a loop.


Sent via Deja.com http://www.deja.com/
Before you buy.