<div dir="ltr">Sorry Kyle I misread your workaround example, it does indeed behave as you described. I didn't know I could do this, interesting. </div><div class="gmail_extra"><br><div class="gmail_quote">On 7 July 2016 at 18:03, Andrew Dawson <span dir="ltr"><<a href="mailto:dawson@atm.ox.ac.uk" target="_blank">dawson@atm.ox.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks both<div><br></div><div>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?<div><br></div><div>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.</div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On 7 July 2016 at 17:09, Kyle Griffin <span dir="ltr"><<a href="mailto:ksgriffin2@wisc.edu" target="_blank">ksgriffin2@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div><span><div style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><font face="monospace, monospace">begin</font></div><div style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><font face="monospace, monospace"> a = (/ 1 /)</font></div><div style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><font face="monospace, monospace"> print(a(1))</font></div><div style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><font face="monospace, monospace"> print("I won't be printed")</font></div></span><div style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><font face="monospace, monospace"> exit</font></div><div style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><font face="monospace, monospace">end</font></div><div style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><font face="monospace, monospace">status_exit(1)</font></div><br></div><div><font color="#333333" face="arial, sans-serif"><span style="font-size:14px;background-color:rgb(245,245,245)">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.</span></font></div><span><font color="#888888"><div><font color="#333333" face="arial, sans-serif"><span style="font-size:14px;background-color:rgb(245,245,245)"><br></span></font></div><div><font color="#333333" face="arial, sans-serif"><span style="font-size:14px;background-color:rgb(245,245,245)"><br></span></font></div><div><font color="#333333" face="arial, sans-serif"><span style="font-size:14px;background-color:rgb(245,245,245)">Kyle</span></font></div></font></span></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 7, 2016 at 9:14 AM Dennis Shea <<a href="mailto:shea@ucar.edu" target="_blank">shea@ucar.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Would the following do what you want?<br><br><a href="http://www.ncl.ucar.edu/Document/Functions/Built-in/status_exit.shtml" target="_blank">http://www.ncl.ucar.edu/Document/Functions/Built-in/status_exit.shtml</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 5:21 AM, Andrew Dawson <span dir="ltr"><<a href="mailto:dawson@atm.ox.ac.uk" target="_blank">dawson@atm.ox.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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?</div><div><br></div><div>Some background:</div><div><br></div>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.<div><br></div><div>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.</div><div><br></div><div>A simple program to reproduce this is:</div><div><br></div><div><div><font face="monospace, monospace">begin</font></div><div><font face="monospace, monospace"> a = (/ 1 /)</font></div><div><font face="monospace, monospace"> print(a(1))</font></div><div><font face="monospace, monospace"> print("I won't be printed")</font></div><div><font face="monospace, monospace">end</font></div></div><div><br></div><div>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.</div><div><br></div><div>I'm using NCL v6.3.0 on Linux x64</div><div><br></div><div>Thanks</div><span><font color="#888888"><div>Andrew<br><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div></div></div></div></div></div></div></div>
</div></font></span></div>
<br>_______________________________________________<br>
ncl-talk mailing list<br>
<a href="mailto:ncl-talk@ucar.edu" target="_blank">ncl-talk@ucar.edu</a><br>
List instructions, subscriber options, unsubscribe:<br>
<a href="http://mailman.ucar.edu/mailman/listinfo/ncl-talk" rel="noreferrer" target="_blank">http://mailman.ucar.edu/mailman/listinfo/ncl-talk</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
ncl-talk mailing list<br>
<a href="mailto:ncl-talk@ucar.edu" target="_blank">ncl-talk@ucar.edu</a><br>
List instructions, subscriber options, unsubscribe:<br>
<a href="http://mailman.ucar.edu/mailman/listinfo/ncl-talk" rel="noreferrer" target="_blank">http://mailman.ucar.edu/mailman/listinfo/ncl-talk</a><br>
</blockquote></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Dr Andrew Dawson<br>Atmospheric, Oceanic & Planetary Physics<br>Clarendon Laboratory<br>Parks Road<br>Oxford OX1 3PU, UK<br>Tel: <a href="tel:%2B44%20%280%291865%20282438" value="+441865282438" target="_blank">+44 (0)1865 282438</a><br>Email: <a href="mailto:andrew.dawson@physics.ox.ac.uk" target="_blank">andrew.dawson@physics.ox.ac.uk</a><div>Web Site: <a href="http://www2.physics.ox.ac.uk/contacts/people/dawson" target="_blank">http://www2.physics.ox.ac.uk/contacts/people/dawson</a></div></div></div></div></div></div></div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Dr Andrew Dawson<br>Atmospheric, Oceanic & Planetary Physics<br>Clarendon Laboratory<br>Parks Road<br>Oxford OX1 3PU, UK<br>Tel: +44 (0)1865 282438<br>Email: <a href="mailto:andrew.dawson@physics.ox.ac.uk" target="_blank">andrew.dawson@physics.ox.ac.uk</a><div>Web Site: <a href="http://www2.physics.ox.ac.uk/contacts/people/dawson" target="_blank">http://www2.physics.ox.ac.uk/contacts/people/dawson</a></div></div></div></div></div></div></div></div>
</div>