fix(cli): graceful handling for mwclient/requests exceptions

[tosfos]

Catch MwClientError (LoginError, APIError, etc.) and RequestException (ConnectionError, Timeout) from build_site(), method(), maybe_convert_markdown() (site.parse), and iterator iteration. Print a clean message to stderr and exit 1 instead of dumping a raw traceback.

• Add _handle_runtime_error() helper; optionally import requests.exceptions
• Wrap maybe_convert_markdown in same try/except as method() so parse() failures are handled
• Tests: APIError, ConnectionError, and iterator mid-stream raise

Made with Cursor

[greptile-apps]

Greptile Summary

This PR adds graceful CLI error handling for runtime failures from mwclient and requests. The main changes are:

• Clean stderr messages and exit code 1 for mwclient errors.
• Clean stderr messages and exit code 1 for requests connection-style errors.
• Exception handling around site creation, method calls, markdown parsing, and iterator consumption.
• Tests for API errors, connection errors, and mid-stream iterator failures.

Confidence Score: 5/5

The changes are narrowly scoped to CLI runtime error handling and accompanying tests.

The implementation covers the intended mwclient and requests failure paths without introducing additional concerns in the reviewed diff.

T-Rex Logs

What T-Rex did

• I reviewed the pre-change behavior where the base emitted uncaught tracebacks for each scenario, with the harness recording exit_code: EXCEPTION and traceback_present: True per case.
• I confirmed the post-change behavior where the head now returns exit_code: 1 per case with concise stderr and traceback_present: False, and the iterator case preserves the first streamed stdout item before returning 1.

_{Ran code and verified through T-Rex}

_{Reviews (2): Last reviewed commit: "fix(cli): graceful handling for mwclient..." | Re-trigger Greptile}

[greptile-apps]

Broad except Exception silently swallows programming errors

All three new try/except blocks catch bare Exception, so any unexpected bug inside build_target, method(), maybe_convert_markdown, or the iterator loop (e.g. an AttributeError, TypeError, or NameError in the CLI code itself) will be caught by the third branch in _handle_runtime_error and printed as "Error: <msg>" with no traceback. This makes accidental regressions hard to distinguish from expected network/API errors. Consider re-raising exceptions that are neither MwClientError nor RequestException (or add a --debug flag to preserve tracebacks for unknown exception types).

Prompt To Fix With AI

This is a comment left during a code review.
Path: mwclient_cli/cli.py
Line: 24-35

Comment:
**Broad `except Exception` silently swallows programming errors**

All three new try/except blocks catch bare `Exception`, so any unexpected bug inside `build_target`, `method()`, `maybe_convert_markdown`, or the iterator loop (e.g. an `AttributeError`, `TypeError`, or `NameError` in the CLI code itself) will be caught by the third branch in `_handle_runtime_error` and printed as `"Error: <msg>"` with no traceback. This makes accidental regressions hard to distinguish from expected network/API errors. Consider re-raising exceptions that are neither `MwClientError` nor `RequestException` (or add a `--debug` flag to preserve tracebacks for unknown exception types).

How can I resolve this? If you propose a fix, please make it concise.