[lfvaranda]

What

ULog() raises uncaught exceptions on malformed .ulg input, aborting the parse (reported in #127). The definitions phase only guarded IndexError, and the data phase only guarded IndexError / end-of-file struct.error, so several failure modes escaped:

Exception	Site	Cause
KeyError (dominant)	_parse_nested_type	ADD_LOGGED_MSG referencing an undefined / nested format
ValueError	_extract_type	malformed array spec (int(...)); also an unclamped array_size → range() DoS
struct.error	_MessageInfo / _MessageFlagBits / _MessageHeader	struct.unpack in the definitions phase (only IndexError was caught there)
OverflowError	_load_file	file.seek() with a bogus appended offset from FLAG_BITS

Fix

Treat these as corruption, consistent with the existing IndexError handling:

• _read_file_definitions: move the header parse into the try and broaden the handler to (IndexError, ValueError, KeyError, OverflowError, struct.error).
• _read_file_data: broaden the per-message handler to also catch KeyError, ValueError, OverflowError.
• _extract_type: reject an out-of-range array_size (also prevents a range()-based resource-exhaustion DoS).
• _load_file: guard the appended-data seek() against a bogus offset.

String decoding errors with disable_str_exceptions=False (UnicodeDecodeError) still propagate, as before.

Valid logs are unaffected; only malformed records are skipped / flagged (file_corruption stays True).

Dedicated exceptions

Intentional refusals now use dedicated exceptions (new pyulog/exceptions.py, exported from pyulog) instead of generic built-ins:

Case	Before	Now
invalid file header	TypeError	ULogException
unknown incompatible flag	ValueError / NotImplementedError	ULogIncompatibleFlagException (subclass of ULogException)

Callers can catch every intentional refusal with a single except ULogException.

Verification

Fuzzing ULog() on mutated valid logs (seed=1, 4000 iterations):

	parses OK	distinct escaping exceptions
before	3255 / 4000	10
after	3971 / 4000	3

The 3 that remain are the intended refusals above (ULogException for an invalid header, ULogIncompatibleFlagException at the two incompatible-flag checks). The genuine robustness gaps (KeyError, _extract_type ValueError, definitions-phase struct.error, _load_file OverflowError) are gone.

New tests in test/test_ulog.py cover both exceptions, corrupt definitions and strict string parsing; pytest and pylint pass.

Fixes #127

[bkueng]

Flight review already has a broad exception capture around parsing.
This makes sense nonetheless though.
And I would directly add a dedicated ULogException while you're at it (with a separate class for the incompatible flag case).

[bkueng]

Can you add a dedicated exception so no string check is required?

[lfvaranda]

Done in 0d297a9: the incompatible-flag case now raises ULogIncompatibleFlagException (a ULogException subclass), which the corruption handler doesn't catch, so no string check is needed.

[lfvaranda]

Thanks for the review! Good to know Flight Review already catches this, so the PR is mainly about robustness for other users of the library.

Updated in 0d297a9:

• Added ULogException and its subclass ULogIncompatibleFlagException in a new pyulog/exceptions.py, exported from pyulog (I kept them out of core.py, which is right at pylint's max-module-lines).
• An invalid header now raises ULogException (was TypeError), and an unknown incompatible flag raises ULogIncompatibleFlagException (was ValueError / NotImplementedError). Neither is caught by the corruption handlers, so the string check is gone.
• While at it, I noticed the broadened handlers also swallowed UnicodeDecodeError (a ValueError subclass), so string errors were treated as corruption even with disable_str_exceptions=False. It propagates again, as before this PR.
• Added tests for both exceptions, corrupt definitions and strict string parsing.

Note that this changes the exception types for these cases, so a caller catching TypeError / ValueError there would need ULogException instead. If you prefer, I can also derive the new classes from the old built-in types for backward compatibility.

[bkueng]

Nice, thanks!

Note that this changes the exception types for these cases, so a caller catching TypeError / ValueError there would need ULogException instead. If you prefer, I can also derive the new classes from the old built-in types for backward compatibility.

I'll mention it in the release notes, that should be sufficient

[bkueng]

Nice, thanks!

Note that this changes the exception types for these cases, so a caller catching TypeError / ValueError there would need ULogException instead. If you prefer, I can also derive the new classes from the old built-in types for backward compatibility.

I'll mention it in the release notes, that should be sufficient