[ncl-talk] NCL exit code on failure

Kyle Griffin ksgriffin2 at wisc.edu
Thu Jul 7 10:09:00 MDT 2016


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20160707/478e527e/attachment.html 


More information about the ncl-talk mailing list