On 03/01/2016 03:54 PM, Robert Hanson wrote:
> 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]
>
Yes I know. I rather thought to use the very few success codes (maybe 
only '200', but even this will be no guarantee) and regard everything 
else as error.

> 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.
>
Thank you for the detailed explanation, Bob. I think it would be a good 
idea to update the 'try / catch' documentation with some of this 
information. Especially because the example there is on catching file 
load errors, leading easily into the wrong direction (as you could see).

> 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
> }
>
Actually it is not that easy for me because advanced/admin users will be 
able to extend my system to read other kinds of files and write their 
own parsers. File loading and parsing are separated and I was rather 
aiming at the more fundamental problems like 'file not found'.

Since I thought 'try / catch' would already be able to do what I would 
need and there might just be a bug in there, I havn't tried yet to come 
up with a different solution. You are right that I could build something 
on my own. But as always when standard output and standard error are 
mixed, it will be notbe easy to distinguish between output and error 
(especially with very flexible input options).

Regards,
Rolf

-- 

Rolf Huehne
Postdoc

Leibniz Institute on Aging - Fritz Lipmann Institute (FLI)
Beutenbergstrasse 11
07745 Jena, Germany

Phone:   +49 3641 65 6205
Fax:     +49 3641 65 6210
E-Mail:  rolf.hue...@leibniz-fli.de
Website: http://www.leibniz-fli.de

           Scientific Director: Prof. Dr. K. Lenhard Rudolph
        Head of Administration: Dr. Daniele Barthel
Chairman of Board of Trustees: Burkhard Zinner

VAT No: DE 153 925 464
Register of Associations: No. 230296, Amtsgericht Jena
Tax Number: 162/141/08228


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

Reply via email to