dzlib has no consistent error handling pattern: some functions return a Boolean, some raise an exception, some fail silently.
The library already has a convention in places, e.g. GetHdVolumeName / TryGetHdVolumeName in u_dzOsUtils: the Try function returns a Boolean with an out parameter, the other raises. A first worked example: GetModuleFilename in src/u_dzOsUtils.pas returns an empty string when Windows.GetModuleFileName fails, so the caller cannot tell failure from anything else. Adding TryGetModuleFilename and having GetModuleFilename raise EOSError would apply the convention; it changes what every consuming program sees on failure, so it should be done once the guideline is settled.
Also tracked as issue 11 in dzlib's ISSUES.md.