Raise the underlying cause when geospatial data cannot be read

[rajeeja]

Closes #1693

• _gpd_read caught every read failure, printed it, and fell through, leaving gdf unbound so the next line raised UnboundLocalError instead of the real cause; dropped the try/except entirely so geopandas raises directly (also surfaces FileNotFoundError for free).
• geopandas was unpinned and pre-1.0 releases don't require pyogrio, so an install could end up with no file-IO backend at all; pinned geopandas>=1.0.
• _open_dataset_with_fallback now chains the fallback engine's error onto the default engine's, so a file neither engine can open reports both reasons.
• FESOM2 ASCII parsers raised FileNotFoundError("TODO: "); now name the missing file/directory.
• Assuming WGS84 for CRS-less data and skipping an unsupported geometry type are now warnings.warn instead of print; the latter previously produced a grid silently missing a face.
• Removed _is_structured's speculative stdout diagnostics, which fired on every valid MPAS/Exodus/SCRIP file.

[Sevans711]

Good find, I definitely agree with this premise of needing better error handling here; the version on main is not using best practices for error handling in a few different ways: (1) try multiple things at once; (2) catch error and print but don't re-raise, and (3) then continue with the code which will crash with confusing UnboundLocalError if an error occurred previously.

I am not 100% certain that GridInvalidError is the way to go here. What if the file simply doesn't exist, for example? Then it should be a FileNotFoundError. I think at least this case needs to be handled separately. Perhaps changing "except Exception" to "except ValueError" would be a cleaner way to do this. I tend to be skeptical of "except Exception" unless there is a clear reason for wanting to catch every error type.

More on that point, though: what is the motivation for catching errors here at all? Why not just allow gpd.read_file(...) to fail directly with its own error message?

[rajeeja]

I hit this by accident — testing something unrelated and saw four failures in test_geopandas.py. Looked like a broken env at first, but geopandas was unpinned in pyproject.toml, and pre-1.0 geopandas doesn't require pyogrio, so my install landed on geopandas 0.9 with no file-IO backend at all — neither pyogrio nor fiona is mentioned anywhere in the repo or ci/environment.yml. Real message was the 'read_file' function requires the 'pyogrio' or 'fiona' package, but neither is installed; the old code printed it and carried on, which is how it became an UnboundLocalError.

You're right that we shouldn't be catching here at all — none of the other readers do; _esmf, _scrip, and io/utils only raise GridInvalidError once the data is parsed and actually wrong. Dropped the try/except and let geopandas raise, which also gets FileNotFoundError for free. except ValueError wouldn't have helped either way, since the real failures are ImportError or pyogrio's DataSourceError / fiona's DriverError — moot now that the catch is gone.

Pinned geopandas>=1.0 and fixed my test too — it was passing on the ImportError rather than a parse failure, green for the wrong reason.

[Sevans711]

Looks pretty reasonable as an overall set of changes to make, but I left a variety of inline comments to be addressed, including one point where I just needed a bit more clarification on the reason for the changes. Thank you for doing this work to improve the clarity and error handling throughout the code!

Flagging #1617 as related (may want to delay any work there on uxarray/io error messages until this merges, since this touches multiple errors in uxarray/io).

[Sevans711]

Looks ready to merge, thank you for implementing this fix and for all the back and forth while addressing my comments!