| Re: openr and /get_lun [message #19736 is a reply to message #19734] |
Sun, 16 April 2000 00:00   |
mallors
Messages: 76
Registered: November 1997
|
Member |
|
|
In article <onitxkz7p7.fsf@cow.physics.wisc.edu>,
Craig Markwardt <craigmnet@cow.physics.wisc.edu> writes:
>
> I have noticed that the use of /GET_LUN and ERROR keywords to openr is
> not as helpful as I would have hoped. Do other have this experience?
> The problem is that when an error occurs, it is hard to know whether
> the file unit was "gotten" or not.
>
> For example:
>
> pro test1
> openr, unit, filename, /get_lun, error=err
> free_lun, unit
> end
>
> If there was an error, then it is possible that UNIT was never set,
> and is hence undefined. FREE_LUN doesn't take undefined variables.
I guess I never thought about it too much, because if
there is an error with the OPEN, then I should handle
it somehow:
OPENR, fl, 'nofile', /GET_LUN, ERROR = error
IF (error NE 0) THEN BEGIN
MESSAGE, /CONTINUE, 'Could not open file.'
RETURN
ENDIF
.
.
.
FREE_LUN, fl
Otherwise, if you don't want to handle the error, you can just
free the unit number conditionally, as I am sure you know:
IF (error EQ 0) THEN FREE_LUN, fl
I sure wish we had a boolean datatype - the mistake of
using something like "IF (NOT error) THEN" is one that
is really a pain to find, although it certainly makes
your code much more readable.
-bob
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~
Robert S. Mallozzi 256-544-0887
Mail Code SD 50
http://gammaray.msfc.nasa.gov/ Marshall Space Flight Center
http://cspar.uah.edu/~mallozzir/ Huntsville, AL 35812
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
