Subject: cfitsio status variable

From: kimball at stsci.edu (Timothy Kimball)
Date: Mon, 6 Jun 1994 15:17:51 GMT

I'm using cfitsio.  It looks like the status variable doesn't get
changed if an error doesn't occur, meaning that it should be cleared
before each cfitsio call.  Is that correct or am I missing something?

Tim Kimball
kimball at stsci.edu
(410) 338-4417

---

From: vesper at enif.astro.indiana.edu (Dave Vesper)
Date: Mon, 6 Jun 1994 18:06:25 GMT

> before each cfitsio call.  Is that correct or am I missing something?
If any FITSIO subroutine is input a non-zero status, the routine will 
return without changing any variables or performing any function. The intent 
is that if you have several calls to FITSIO subroutines in a row, you don't 
have to check for an error after each call. Instead, you can check the status after all the calls, without fear that an early error will cause problems with 
later FITSIO calls. So if you want to procede after an error, you do need to 
reset the status variable. Instead of clearing it before each call, I'd clear
it after resolving (or noting) the condition that caused the non-zero status. 

					Dave

---

From: kimball at stsci.edu (Timothy Kimball)
Date: Fri, 10 Jun 1994 22:37:25 GMT

Dave Vesper (vesper at enif.astro.indiana.edu) wrote:
: If any FITSIO subroutine is input a non-zero status, the routine will 
: return without changing any variables or performing any function. The intent 
: is that if you have several calls to FITSIO subroutines in a row, you don't 
: have to check for an error after each call. Instead, you can check the status after all the calls, without fear that an early error will cause problems with 
: later FITSIO calls. So if you want to procede after an error, you do need to 
: reset the status variable. Instead of clearing it before each call, I'd clear
: it after resolving (or noting) the condition that caused the non-zero status. 

Hmmm...runs contrary to the philosophy about having enough rope to hang
yourself, doesn't it?  Not that I would ever try to read from a file that
wasn;t successfully opened, but I was expecting that the library would
leave the error checking to me, and not try to take on the job itself.

-- tdk

---

From: mjc at adam3.bnsc.rl.ac.uk (Malcolm Currie)
Date: 28 Jun 1994 17:03:30 GMT

In article <1994Jun10.223725.4513 at stsci.edu>, kimball at stsci.edu (Timothy Kimball) writes:
|>From: kimball at stsci.edu (Timothy Kimball)
|>Subject: Re: cfitsio status variable
|>Organization: Space Telescope Science Institute
|>
|>Dave Vesper (vesper at enif.astro.indiana.edu) wrote:
|>: If any FITSIO subroutine is input a non-zero status, the routine will 
|>: return without changing any variables or performing any function. The intent 
|>: is that if you have several calls to FITSIO subroutines in a row, you don't 
|>: have to check for an error after each call. Instead, you can check the status after all the calls, without fear that an early error will cause problems with 
|>: later FITSIO calls. So if you want to procede after an error, you do need to 
|>: reset the status variable. Instead of clearing it before each call, I'd clear
|>: it after resolving (or noting) the condition that caused the non-zero status. 
|>
|>Hmmm...runs contrary to the philosophy about having enough rope to hang
|>yourself, doesn't it?  Not that I would ever try to read from a file that
|>wasn;t successfully opened, but I was expecting that the library would
|>leave the error checking to me, and not try to take on the job itself.

We've been using this design in Starlink for many years.  It makes
applications quicker to write and easier to follow.  The subroutine
that detects an error makes an error report and sets a bad status.
Thus programmers don't need to make lots of error reports and checks
at higher levels.

Malcolm Currie
Starlink Project