[ncl-talk] NCL exit code on failure

Andrew Dawson dawson at atm.ox.ac.uk
Thu Jul 7 11:03:13 MDT 2016


Thanks both

Kyle - The workaround you suggest certainly returns 1, but does so also on
success (i.e. when the line that causes an error is commented out) so this
isn't particularly useful, unless I've misunderstood?

Dennis - We re already using status_exit when we have detected an error
condition we were expecting. However, I'm referring to a scenario where an
un-handled error causes NCL to abort a script, it'd be great if this could
return non-zero to the shell automatically.

On 7 July 2016 at 17:09, Kyle Griffin <ksgriffin2 at wisc.edu> wrote:

> I'm going to jump in here as well - I believe the status_exit(x) call
> would do what is asked (if it can be inserted at the appropriate locations
> that check for all possible conditions that could lead to an error being
> thrown), but Andrew appears to ask about the default behavior of NCL, which
> is to return exit code 0 regardless of what happened in execution.
>
> My interpretation (and something that I believe I experimented with a
> couple years ago) was that this is a request for any "fatal: ..." errors to
> throw a different exit code (presumably a simple 1), as do many other shell
> programs to signal an unsuccessful execution.
> I'm sure this is trickier behind the scenes than it sounds, but those of
> us who use NCL for real-time or other automated processes would really
> benefit from this simple change.
>
> Andrew - Now that I go back and look at a previous question on the same
> topic (ticket NCL-1528), you should be able to add a "status_exit(1)" call
> after your end statement to simulate this behavior in some cases, e.g.
>
> begin
>     a = (/ 1 /)
>     print(a(1))
>     print("I won't be printed")
>     exit
> end
> status_exit(1)
>
> While this should work for your example above, this workaround doesn't
> catch errors that arise in other NCL functions (e.g. addfile), presumably
> because they have their own begin/end block. Depending on where your errors
> commonly arise, this might provide you some improvement in usability, but
> the issue of error handling remains unaddressed in the wider scope of NCL
> functions.
>
>
> Kyle
>
> On Thu, Jul 7, 2016 at 9:14 AM Dennis Shea <shea at ucar.edu> wrote:
>
>> Would the following do what you want?
>>
>> http://www.ncl.ucar.edu/Document/Functions/Built-in/status_exit.shtml
>>
>> On Thu, Jul 7, 2016 at 5:21 AM, Andrew Dawson <dawson at atm.ox.ac.uk>
>> wrote:
>>
>>> I'd like to know if it is possible to make NCL exit with a non-zero
>>> status when it encounters a fatal error such as a subscrip error while
>>> running a script? If not, could this be considered for a future version?
>>>
>>> Some background:
>>>
>>> We are running an NCL program in a batch job, and would like to detect
>>> if the NCL program has failed. Within the program we have error checking
>>> that calls status_exit with a non-zero status when we identify a fatal
>>> error, and we can detect these errors from the shell script that calls NCL
>>> via the process exit status $?. All fine so far.
>>>
>>> However, we discovered one of our programs may sometimes suffer a
>>> run-time error due to incomplete data files, the form of this error is a
>>> subscript out of range error, a fatal error that terminates the NCL
>>> process. Unfortunately when NCL terminates it returns exit status 0, so we
>>> cannot detect the failure directly in the shell. Instead we have to either
>>> capture the output of the program and search for error messages, or
>>> re-write the program so that this potential error condition is explicitly
>>> checked and use a manual call to status_exit.
>>>
>>> A simple program to reproduce this is:
>>>
>>> begin
>>>     a = (/ 1 /)
>>>     print(a(1))
>>>     print("I won't be printed")
>>> end
>>>
>>> When run this program will terminate with a fatal error on the second
>>> line, and the last line will not be executed, but the exit status of the
>>> ncl process will be 0. It would be super convenient if the exit status was
>>> non-zero in this case.
>>>
>>> I'm using NCL v6.3.0 on Linux x64
>>>
>>> Thanks
>>> Andrew
>>>
>>> _______________________________________________
>>> ncl-talk mailing list
>>> ncl-talk at ucar.edu
>>> List instructions, subscriber options, unsubscribe:
>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>>
>>>
>> _______________________________________________
>> ncl-talk mailing list
>> ncl-talk at ucar.edu
>> List instructions, subscriber options, unsubscribe:
>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>
>


-- 
Dr Andrew Dawson
Atmospheric, Oceanic & Planetary Physics
Clarendon Laboratory
Parks Road
Oxford OX1 3PU, UK
Tel: +44 (0)1865 282438
Email: andrew.dawson at physics.ox.ac.uk
Web Site: http://www2.physics.ox.ac.uk/contacts/people/dawson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20160707/bb72b8f8/attachment-0001.html 


More information about the ncl-talk mailing list