[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: openr and /get_lun



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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~