Error Handling and Exception Management

[mraffly]

Purpose of the improvement

This refers to issue 7 in the documentation https://iffmd.fz-juelich.de/zXxTrardSNaJc4a22gNypw?view

The main issue is the overestimation of how exceptions are detected.

There are two main points here:

• Bare Except Clauses
• Overly Broad Exception Handling

Bare Except Clauses

There is the issue that two instances of bare except: clauses that catch all exceptions. This has the risk that:

• Catches system exceptions like KeyboardInterrupt and SystemExit
• Makes debugging difficult by hiding real error messages
• Violates Python best practices

Bare Except Clauses show up in these files:

• fine/aggregations/technologyAggregation/techAggregation.py
• fine/aggregations/spatialAggregation/manager.py

Example from fine/aggregations/spatialAggregation/aggregation.py:

FINE/fine/aggregations/spatialAggregation/aggregation.py

Line 417 in b90119a

except Exception:

Recommendation for Bare Except Clauses

Replace with specific exception types:
except (FileNotFoundError, OSError) as e:
raise FileNotFoundError("The gridded_RE_ds path specified is not valid") from e

Overly Broad Exception Handling

This shows up in 11 instances across multiple files.

The issue is that the use of "except Exception:" is too broad and catches nearly all errors.

Following files contain broad exception handling:

• fine/aggregations/technologyAggregation/techAggregationUtils.py:115
• fine/aggregations/spatialAggregation/aggregation.py:417, 428
• fine/IOManagement/utilsIO.py:327, 428, 452, 476, 540
• fine/energySystemModel.py:2014, 2030
• fine/subclasses/lopf.py:110

Example based on fine/aggregations/spatialAggregation/aggregation.py:

FINE/fine/aggregations/spatialAggregation/aggregation.py

Line 417 in b90119a

except Exception:

The drawback of this method is:

• Hides unexpected errors and bugs
• Makes troubleshooting difficult
• Can mask programming errors

Recommendation to fix this issue:

Use specific exception types for each case