OfflineEmissionsTracker silently returns a half-built object when construction fails #1311

When OfflineEmissionsTracker is constructed with an invalid configuration, no exception is raised. The constructor returns a partially initialised object, every subsequent call fails silently, and the run produces no emissions data at all. The online EmissionsTracker raises correctly for the same input, so the two constructors have opposite error semantics.

Reproduction

from codecarbon import OfflineEmissionsTracker

tracker = OfflineEmissionsTracker(country_iso_code="FRA", output_dir="/does/not/exist")
tracker.start()
# ... user workload ...
print(tracker.stop())   # None, and emissions.csv was never written

EmissionsTracker(output_dir="/does/not/exist") raises OSError: Folder ... does not exist ! as expected.

Root cause

OfflineEmissionsTracker.__init__ is decorated with @suppress(Exception) at codecarbon/emissions_tracker.py:1312. The validation in BaseEmissionsTracker._set_from_conf (codecarbon/emissions_tracker.py:138-140) raises OSError, but the decorator swallows it, so super().__init__ never reaches _initialize_runtime_state() / _initialize_scheduler_state() (codecarbon/emissions_tracker.py:603-604). The object then has no _start_time, _hardware, _scheduler or _output_handlers.

start() and stop() are also @suppress(Exception) (lines 692 and 886), so the resulting AttributeError: OfflineEmissionsTracker object has no attribute _start_time is downgraded to warnings as well. Under the CLI default log_level="error" (codecarbon/cli/main.py) nothing is printed at all.

suppress itself lives at codecarbon/core/util.py:21-30.

Expected vs actual

• Expected: a misconfigured offline tracker raises at construction time, like the online tracker does.
• Actual: construction succeeds, start()/stop() no-op with warnings, stop() returns None, and no emissions file is produced. Users reasonably conclude CodeCarbon does not work on their machine.

Suppressing exceptions in start/flush/stop is deliberate and should stay: CodeCarbon must never crash a training job at runtime. The decorator on the constructor is a different case, since failure there means the object invariants were never established.