I am trying Python 3 on Rhino 8. However, when I use a local package for a script, there is some wrong. This script calls for one XML file from my local folder. If I input the wrong path, ghpython would stop working and give me a error messge: XML Parsing error inside file. File not found. And Rhino would stop working and shut down itself. I don’t want the Rhino to shut down everytime I input a wrong script.
Why can’t you simply input the correct path (preferably an absolute path, with no non-ascii chars)?
Otherwise in your code, you must check that the path exists and leads to a supported file. If you must hardcode a windows path in your source as a string literal, raw strings allow you to avoid escaping every directory separator, e.g.: r'C:\Users\user_name\AppData\Roaming\Grasshopper' and copy and paste them straight in from File Explorer. Manipulate paths with os.path, or pathlib in Python 3.
There’s no built in way to get CPython, GhPython, or any type of Python to handle “the wrong path”, for all the possible ways a path could be wrong.
By the way, GhPython components can look up a .3dm and .gh file’s path, but these paths only exist if the user has saved their work.
Thanks for your reply. What I mean is that If I accidentally enter an incorrect path,which is possible to happen, the Rhino would shut down itself and send the error message in my case. I don’t wish this to happen.
I am not sure how you are loading your file, but it seems that for me Rhino/GH/Python3 is able to execute the typical open() command with a missing/wrong file location without an application error?
For me, the native xml.etree also seems to handle missing/wrong XML files without an application error (assuming you are using the native etree library):
For any user-input, some for of explicit validation and checking is always a good idea. Useful/helpful exceptions should be raised (and execution halted) if any data is invalid before proceeding with the rest of the script.
Using the with open(...) context-manager idiom is good practice and helps to manage errors when opening files.
Putting your script execution or commands like open(...) inside try...except... blocks is good practice and can help avoid many types of application errors. I find that especially when working with user-input these try...except... blocks are really useful for catching weird or unexpected inputs.
Using custom exceptions to provide useful feedback/instructions to users is also a good idea and helps with logging and debugging.
So while the normal etree parser should already handle invalid paths, if you are still having trouble with it and wanted to be really extra careful with it, then something like:
import xml.etree.ElementTree as ET
try:
tree = ET.parse(_file_path)
except FileNotFoundError as e:
raise e
# If no exceptions are thrown while loading the
# file, the rest of the script will continue....
# ...
Thanks a lot for your information. I load it as this: Path = “E:\ aaa \ bbb.xml”. And this Path is used by a local package. If I just run the wrong path in python outside grasshopper, it would give me error feedback without shutting down, which is normal. But in Rhino grasshopper, the case is different.
Your suggestions on how to handle invalid paths are really helpful.