René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Uncaught exception when a component has a property whose getter raises (intended?)","articleBody":"When a component has a `@property` whose getter raises, `fire.Fire(component)` crashes with the property's raw traceback on bare invocation and on `--help`, instead of showing usage/help. A direct call to an unrelated method works fine.\n\nRepro (fire 0.7.1):\n\n```python\nimport fire\n\nclass App:\n    @property\n    def status(self):\n        raise RuntimeError(\"backend unavailable\")  # e.g. a lazy / fallible getter\n\n    def greet(self, who=\"world\"):\n        return f\"hi {who}\"\n\nif __name__ == \"__main__\":\n    fire.Fire(App())\n```\n\n```\n$ python app.py --help\n  ...\n    value = getter(object, key)\n  File \"app.py\", line 5, in status\n    raise RuntimeError(\"backend unavailable\")\nRuntimeError: backend unavailable\n\n$ python app.py greet        # works\nhi world\n```\n\nFire enumerates members (and reads property *values*) during help/listing, so any property getter that can raise (lazy config, DB or network access, etc.) takes down `--help` and bare invocation, even though those properties are never invoked.\n\nIs this intended, or should Fire surface a clean error (or skip properties that raise) during member enumeration? Happy to send a PR if a fix would be welcome.\n\n\u003csub\u003eFound via automated analysis and confirmed with the reproducer above on fire 0.7.1.\u003c/sub\u003e\n","author":{"url":"https://github.com/Lougarou","@type":"Person","name":"Lougarou"},"datePublished":"2026-06-06T08:04:58.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":5},"url":"https://github.com/672/python-fire/issues/672"}