Previously, we passed a variable that contained either a JSON string or a path to a JSON file to the Path constructor, using my_path.exists to determine whether we were handling the former or the latter. However, with long JSON strings (255 characters/bytes in most cases), this prompted my_path.exists to raise an OSError 💣.
We could rewrite the function to parse the variable as if it were a JSON string first and, if that failed, then open it as if it were a path to a JSON file second. However, we would need nested try/except blocks; if parsing the variable as if it were a JSON string failed because of bad JSON, rather than because it was a path to a JSON file, then we couldn't report this to the user. As someone who has been bitten by systems that write out bad JSON -- with single quotes rather than double quotes, for example -- I think this approach is sub-optimal. Hence catching OSError instead.
Previously, we passed a variable that contained either a JSON string or a path to a JSON file to the
Pathconstructor, usingmy_path.existsto determine whether we were handling the former or the latter. However, with long JSON strings (255 characters/bytes in most cases), this promptedmy_path.existsto raise anOSError💣.We could rewrite the function to parse the variable as if it were a JSON string first and, if that failed, then open it as if it were a path to a JSON file second. However, we would need nested
try/exceptblocks; if parsing the variable as if it were a JSON string failed because of bad JSON, rather than because it was a path to a JSON file, then we couldn't report this to the user. As someone who has been bitten by systems that write out bad JSON -- with single quotes rather than double quotes, for example -- I think this approach is sub-optimal. Hence catchingOSErrorinstead.Closes #18