It's harder than you think. There are several other messages that can come
up besides 404 that would signify a file read failure [
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes]
try/catch is primarily for *Jmol scripting errors. *Just like try/catch in
JavaScript is for JavaScript errors, and try/catch in Java is for Java
errors. To the extent that a Java error results in a command failure in
Jmol, they will be caught. But Java errors are rare in running Jmol code.
It is true that Java errors (actually Java *exceptions*) occur for the LOAD
and WRITE commands and in that case do trigger try/catch errors.
With the LOAD command, we are not catching 404 or any such message. Jmol
just discovers that there is no such file format. So try/catch is catching
a Jmol scripting error, not technically the Java exception. The load()
function works the same. It's just that there is no Jmol processing that
goes on to check the file's validity, so there is no catch.
Since you know what kind of files you are after, you can add your own THROW
command:
try{
x = load("asfadf")
if (x.find("404") || x.find("Exception")) throw x
//...more here...
} catch(e) {
print "load() error: " + e
}
Bob
My feeling is that
On Mon, Feb 29, 2016 at 5:11 PM, Rolf Huehne <rolf.hue...@leibniz-fli.de>
wrote:
> Am 29.02.16 um 23:10 schrieb Robert Hanson:
> > I believe that is the correct behavior. It's just that in the case of
> > the JavaScript version of the applet you get an HTML error message, and
> > in Java you get a Java error message. Your code is just printing that
> > error message (fileData).
> >
> > But I see. you were expecting load("xxxx") to throw an error instead.
> > That does make sense to me. But, if you think about it, there's no way
> > for the applet to know what the HTML will be that defines a "file not
> > found" error. These messages vary a lot. It is tested when you actually
> > /load /the file, because we know in that case what the options are, and
> > those error messages are not of them.
> >
> > But with load("xxxx") the file to load could be anything, including a
> > file that reports exactly that HTML. So it never throws an error, and
> > you just have to check to make sure yourself that you have the data you
> > expect.
> >
> I am confused.
> Isn't a Java exception exactly what a 'try / catch' is intended for?
> And in the case of a http request : couldn't Jmol use the http response
> code (e.g.: 200 => ok, 404 => file not found) to recognize errors?
>
> Regards,
> Rolf
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
--
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
