[Feature Request] Improve Python code generation patterns: exception handling, error logging, and API sync safety

Bug Description

# Code Review: Frequent Issues in Claude-Generated Python Code I have found (at least) 3 frequent issues in the code generated by Claude for Python: ## 1. Overuse of Generic Exception The usage of the generic Exception — to me, as a senior engineer, the generic Exception should almost never be used, as it cannot be handled properly. ``python # ❌ Bad try: do_something() except Exception as e: handle(e) # ✅ Better try: do_something() except (ValueError, TimeoutError) as e: handle(e) ` ## 2. Silent continue in Loops Without Logging or Error Raising When some illogical case happens in a loop, it just puts an if ...: continue with no error raised and no logs. This has the impact of silently ignoring errors that occur, which could have major side effects in production. `python # ❌ Bad for item in items: if not is_valid(item): continue # Silent failure — no log, no raise # ✅ Better for item in items: if not is_valid(item): logger.warning(f"Skipping invalid item: {item!r}") continue ` ## 3. Delete-Before-Confirm When Syncing with 3rd-Party APIs When dealing with a 3rd-party API to sync data from the DB to the API, and afterwards cleaning the data in the DB — Claude commits the deletion, keeps the data in memory, and pushes it to the 3rd-party API. Result: if the 3rd-party API raises an error, the data is lost and we cannot reproduce the sync because there is no data. `python # ❌ Bad — deletes from DB before confirming API success data = db.fetch(...) db.delete(...) # Data is gone api.push(data) # If this fails, data is lost forever # ✅ Better — confirm success before cleaning up data = db.fetch(...) api.push(data) # Push first db.delete(...) # Only clean up after confirmed success `` > Rule of thumb: Never destroy your source of truth before confirming the downstream operation succeeded. Always follow the write-ahead / commit-last principle.

Environment Info

• Platform: darwin
• Terminal: pycharm
• Version: 2.1.145
• Feedback ID: 8ab6a4ee-47a9-414b-bdc1-627d156c998b

Errors

[]