Catch specific, meaningful exceptions

When handling errors, catch the narrowest exception type that accurately represents the failure, and avoid broad except:/except Exception blocks that silently swallow errors or hide tracebacks needed for debugging. If a broad catch is truly required (e.g. Python 2 compatibility where exceptions may not derive from BaseException), make the intent explicit in a comment and ensure the resulting behavior is still correct—don’t let it mask unrelated bugs.

Avoid fragile heuristics such as matching on exception message text to decide how to react to an error (e.g. checking str(exc_value).startswith(...) to detect a wrong-arguments TypeError); these break easily and can misclassify errors raised by unrelated code. Prefer structural checks instead, such as inspecting the exception’s type/traceback frames, e.g.:

def _called_with_wrong_args(factory, exc_info):
    _, _, tb = exc_info
    while tb.tb_next:
        tb = tb.tb_next
    return tb.tb_frame.f_code.co_name == factory.__name__

When an error must be suppressed to keep a feature usable (e.g. not breaking --help if the app fails to import), catch only the specific exception that represents that known failure mode (like NoAppException) rather than Exception, and still surface a clear message to the user (via print(..., file=sys.stderr) or warnings.warn) instead of silently discarding the error or using ad-hoc print/traceback.print_exc() calls that bypass the normal error-reporting path. This keeps error handling predictable, preserves useful diagnostics, and prevents hidden bugs from being masked by overly permissive exception handling.