Some SDK error paths print directly to stdout/stderr during exception and fallback handling

[sudo-anshul]

Description

While looking through a few query and network paths, I noticed that some SDK
runtime code calls print(...) directly and, in a few places,
traceback.print_exc() as part of internal error handling.

From a contributor/user point of view, this feels a little surprising because
the SDK is a library, and these paths can produce console output even when:

• the caller is already handling the exception
• the method re-raises the same exception immediately
• the SDK falls back and continues successfully

I think it would be nicer if these paths either raised/returned quietly or used
the SDK's logging system instead of printing directly.

Steps to reproduce

Repro 1: query builder prints before re-raising

from hiero_sdk_python.query.token_info_query import TokenInfoQuery

TokenInfoQuery()._make_request()

Actual behavior:

• raises ValueError("Token ID must be set before making the request.")
• also prints Exception in _make_request: Token ID must be set before making the request.

Expected behavior:

• raise the exception without printing directly to stdout

Repro 2: query builder prints and emits traceback

from hiero_sdk_python.query.account_balance_query import CryptoGetAccountBalanceQuery
from hiero_sdk_python.account.account_id import AccountId
from hiero_sdk_python.contract.contract_id import ContractId

query = CryptoGetAccountBalanceQuery()
query.account_id = AccountId(0, 0, 123)
query.contract_id = ContractId(0, 0, 456)
query._make_request()

Actual behavior:

• raises ValueError("Specify either account_id or contract_id, not both.")
• prints an error message to stdout
• emits a traceback to stderr

Expected behavior:

• raise the exception without direct console output

Repro 3: network fallback still prints

If mirror-node discovery fails for a hosted network, Network("testnet") can
still initialize successfully by falling back to default nodes, but it prints
the mirror-node fetch failure to stdout during that process.

Actual behavior:

• network initialization succeeds
• console output still includes Error fetching nodes from mirror node API: ...

Expected behavior:

• fallback should remain intact
• logging/output should be opt-in, not printed directly by the SDK

Additional context

Verified affected locations include:

• src/hiero_sdk_python/query/token_info_query.py
• src/hiero_sdk_python/query/account_info_query.py
• src/hiero_sdk_python/query/account_balance_query.py
• src/hiero_sdk_python/query/token_nft_info_query.py
• src/hiero_sdk_python/file/file_info_query.py
• src/hiero_sdk_python/client/network.py

Examples:

• src/hiero_sdk_python/query/account_balance_query.py:112-115
• src/hiero_sdk_python/client/network.py:191-212

This seems separate from documentation/example print(...) usage. I am only
referring to runtime library paths that emit output during normal exception or
fallback handling.

Also, the repo already has logging infrastructure and other SDK paths appear to
use logger-based diagnostics, so these spots feel a bit inconsistent with that
direction.

Why this matters

This can be noisy for:

• applications embedding the SDK
• CLI tools that want explicit control over output
• tests that assert clean stdout/stderr
• services/workers using structured logging

Possible fix direction

Maybe one of these approaches would fit:

• remove direct print(...) / traceback.print_exc() from these library paths
• re-raise/return without printing directly
• or route diagnostics through the SDK's existing logging mechanisms

I am not suggesting any behavior change to the exception/fallback logic itself,
just to the direct console side effects.

Environment

• Hedera network: testnet for the network fallback reproduction

[github-actions]

Thanks for your submission.

This issue is awaiting approval from @hiero-ledger/hiero-sdk-python-triage and @hiero-ledger/hiero-sdk-python-committers and @hiero-ledger/hiero-sdk-python-maintainers.

[exploreriii]

Excellent idea @sudo-anshul
I approve this issue - the try/except print/re-raise blocks are pure noise eg

try...
       except Exception as e:
            print(f"Exception in _make_request: {e}")
            traceback.print_exc()
            raise

The acceptance criteria would be no print/print_exc in src/ runtime paths
Marking this as a intermediate issue. It is fairly mechanical but does require some thinking about how to use the existing logging module, without preserving bad patterns. So the user needs to consider how to best use the logger, not just reproduce print statements with logging and how to safely dismantle the try except blocks across various files. Tests will need to be created to ensure all works as before, with the new exceptions propagating.
Thank you for your upfront verification work and detailed issue description

[github-actions]

Approved by @hiero-ledger/hiero-sdk-python-triage and @hiero-ledger/hiero-sdk-python-committers and @hiero-ledger/hiero-sdk-python-maintainers.

[github-actions]

@coderabbitai plan

[coderabbitai]

Coding Plan

Summary

Remove the direct print(...)/traceback.print_exc() calls (and now-unused import traceback) from every query builder's _make_request exception handler, letting the original exceptions raise quietly without altering exception types, messages, or control flow.

Extend coverage beyond the six ticket-named files to all runtime files sharing the identical anti-pattern, while explicitly leaving docstring/example prints untouched.

Convert the network mirror-node fallback's two print(...) calls to opt-in logging.getLogger(__name__) warnings, preserving the successful default-node fallback behavior.

Design Choices

Design Choice 1: How should the print/traceback.print_exc() calls inside query builders' _make_request exception handlers be handled?

Options Considered:

1. Remove the print(...)/traceback.print_exc() lines entirely, letting the exception propagate quietly (and drop the now-unused import traceback). If the surrounding try/except block only exists to print-and-reraise, it can be simplified/removed so the original exception raises naturally.
2. Replace the prints with a module-level logger = logging.getLogger(name) and logger.error(..., exc_info=True), matching the stdlib pattern used by sibling query modules.

Chosen Option: 1

Rationale: The exception is re-raised immediately and the caller already receives full context, so quiet re-raise matches the ticket's stated expected behavior ("raise the exception without printing directly") and is the least intrusive, cleanest change; no diagnostic value is lost.

Design Choice 2: How should network.py's two fallback print(...) calls be handled, given Network has no logger and cannot import Client (circular)?

Options Considered:

1. Use a module-level logger = logging.getLogger(name) and emit logger.warning(...), matching the exact pattern already established in sibling mirror-node modules (fee_estimate_query.py, topic_message_query.py, registered_node_address_book_query.py).
2. Thread the Client-owned custom Logger into Network.init, or give Network its own Logger(LogLevel.from_env(), ...) instance.

Chosen Option: 1

Rationale: It is the least invasive, avoids circular imports and constructor changes, keeps Network standalone-usable, makes output opt-in (silent unless the consumer configures logging), and is directly consistent with how the other mirror-node/REST query modules already log.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Silence query builder exception-handler console output

This phase eliminates the copy-pasted "print-then-reraise" anti-pattern across all query builders that override _make_request. The goal is that these builders raise their original exceptions cleanly without writing to stdout/stderr, keeping the raised exception types and messages exactly as they are today. Coverage extends beyond the six files explicitly named in the ticket to every file sharing the identical pattern, so the codebase is left consistent rather than partially fixed.

Task 1: Remove print/traceback from the ticket-named query and file builders

Address the explicitly verified locations first, ensuring their _make_request error paths re-raise quietly.

• Update src/hiero_sdk_python/query/token_info_query.py, src/hiero_sdk_python/query/account_info_query.py, src/hiero_sdk_python/query/account_balance_query.py, src/hiero_sdk_python/query/token_nft_info_query.py, and src/hiero_sdk_python/file/file_info_query.py.
• In each file's _make_request, remove the print(f"Exception in _make_request: {e}") line and, where present, the accompanying traceback.print_exc() line.
• Where the except Exception as e: block now only performs a bare raise, simplify by letting the exception propagate naturally (removing the redundant catch-all) so behavior is unchanged but the console side effect is gone.
• Remove the now-unused import traceback from files where traceback was only used for print_exc() (confirmed as its sole usage in these files).
• Preserve all inner ValueError/AttributeError raises and their messages exactly (e.g., "Token ID must be set...", "Specify either account_id or contract_id, not both.").

Task 2: Apply the same fix to the remaining query builders sharing the pattern

Extend the cleanup to the additional runtime files that contain the identical anti-pattern, for full codebase consistency.

• Update src/hiero_sdk_python/query/topic_info_query.py, src/hiero_sdk_python/query/transaction_get_receipt_query.py, src/hiero_sdk_python/file/file_contents_query.py, src/hiero_sdk_python/account/account_records_query.py, src/hiero_sdk_python/contract/contract_bytecode_query.py, src/hiero_sdk_python/contract/contract_call_query.py, src/hiero_sdk_python/contract/contract_info_query.py, and src/hiero_sdk_python/schedule/schedule_info_query.py.
• Apply the same removal approach as Task 1.1: drop the print(...)/traceback.print_exc() lines, simplify redundant catch-and-reraise blocks, and remove the now-unused import traceback.
• Do not touch docstring/example print(...) usages in tokens/token_type.py, tokens/fee_assessment_method.py, and tokens/assessed_custom_fee.py — these are documentation illustrations, not runtime error handling.

🤖 Prompt for AI agents

Implement Phase 1: remove the copy-pasted print-then-reraise anti-pattern from
all query builders' `_make_request` methods so exceptions propagate quietly
without console output, while keeping exception types/messages unchanged.

Step 1 - Ticket-named files: In
`src/hiero_sdk_python/query/token_info_query.py`,
`src/hiero_sdk_python/query/account_info_query.py`,
`src/hiero_sdk_python/query/account_balance_query.py`,
`src/hiero_sdk_python/query/token_nft_info_query.py`, and
`src/hiero_sdk_python/file/file_info_query.py`:
- In each `_make_request`, remove the `print(f"Exception in _make_request:
{e}")` line and any accompanying `traceback.print_exc()` line.
- If the `except Exception as e:` block now only performs a bare `raise`,
simplify/remove the redundant catch-all so the exception propagates naturally.
- Remove the now-unused `import traceback` where `traceback` was solely used for
`print_exc()`.
- Preserve all inner `ValueError`/`AttributeError` raises and their exact
messages.

Step 2 - Remaining files with the same pattern: Apply the identical
removal/simplification approach to
`src/hiero_sdk_python/query/topic_info_query.py`,
`src/hiero_sdk_python/query/transaction_get_receipt_query.py`,
`src/hiero_sdk_python/file/file_contents_query.py`,
`src/hiero_sdk_python/account/account_records_query.py`,
`src/hiero_sdk_python/contract/contract_bytecode_query.py`,
`src/hiero_sdk_python/contract/contract_call_query.py`,
`src/hiero_sdk_python/contract/contract_info_query.py`, and
`src/hiero_sdk_python/schedule/schedule_info_query.py`.

Do not modify docstring/example `print(...)` usages in `tokens/token_type.py`,
`tokens/fee_assessment_method.py`, and `tokens/assessed_custom_fee.py`, since
those are documentation illustrations, not runtime error handling.

Phase 2: Route network fallback diagnostics through logging

This phase converts the mirror-node discovery fallback in the network layer from direct stdout printing to opt-in logging, keeping the fallback logic (silently defaulting to hardcoded nodes) fully intact so Network("testnet") still initializes successfully.

Replace network.py fallback prints with module-level logging

Make the mirror-node fetch diagnostics silent-by-default and controllable by the embedding application.

• Update src/hiero_sdk_python/client/network.py.
• Add import logging (in the stdlib import group) and declare a module-level logger = logging.getLogger(__name__) after imports, matching the convention already used by fee_estimate_query.py/topic_message_query.py.
• In _fetch_nodes_from_mirror_node, replace print(f"No known mirror node URL for network='{self.network}'. Skipping fetch.") with a logger.warning(...) call conveying the same message.
• Replace print(f"Error fetching nodes from mirror node API: {e}") in the except requests.RequestException as e: block with a logger.warning(...) call conveying the same message.
• Leave the surrounding control flow (returning [] and falling back to default nodes via _resolve_nodes) unchanged.

🤖 Prompt for AI agents

Implement Phase 2: convert `src/hiero_sdk_python/client/network.py`'s
mirror-node fallback diagnostics from direct `print(...)` calls to opt-in
logging, preserving all existing fallback control flow.

- Add `import logging` in the stdlib import group and declare a module-level
`logger = logging.getLogger(__name__)` after the imports, matching the
convention already used in `fee_estimate_query.py`/`topic_message_query.py`.
- In `_fetch_nodes_from_mirror_node`, replace `print(f"No known mirror node URL
for network='{self.network}'. Skipping fetch.")` with an equivalent
`logger.warning(...)` call.
- Replace `print(f"Error fetching nodes from mirror node API: {e}")` (inside the
`except requests.RequestException as e:` block) with an equivalent
`logger.warning(...)` call.
- Do not change the surrounding control flow: the method must still return `[]`
on failure and the caller must still fall back to default nodes via
`_resolve_nodes` exactly as before.

Research

The SDK is a Python library under src/hiero_sdk_python. Query builders (in query/, file/, contract/, schedule/, account/) subclass a common Query/_Executable base and each override _make_request, which builds a protobuf request inside a try block and, on the catch-all except Exception as e:, prints a diagnostic message (sometimes with traceback.print_exc()) before re-raising the original exception unchanged. Separately, client/network.py's _fetch_nodes_from_mirror_node prints two diagnostic messages during mirror-node discovery before silently falling back to default nodes. The codebase already has two logging conventions: a custom Logger wrapper (logger/logger.py, owned by Client as self.logger) and a plain stdlib logging.getLogger(__name__) module-level pattern used by sibling mirror-node query modules (fee_estimate_query.py, topic_message_query.py, registered_node_address_book_query.py). No lint rule currently enforces against print, and no existing tests assert on stdout/stderr for the affected modules, so removals are safe.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: remove the copy-pasted print-then-reraise anti-pattern from
all query builders' `_make_request` methods so exceptions propagate quietly
without console output, while keeping exception types/messages unchanged.

Step 1 - Ticket-named files: In
`src/hiero_sdk_python/query/token_info_query.py`,
`src/hiero_sdk_python/query/account_info_query.py`,
`src/hiero_sdk_python/query/account_balance_query.py`,
`src/hiero_sdk_python/query/token_nft_info_query.py`, and
`src/hiero_sdk_python/file/file_info_query.py`:
- In each `_make_request`, remove the `print(f"Exception in _make_request:
{e}")` line and any accompanying `traceback.print_exc()` line.
- If the `except Exception as e:` block now only performs a bare `raise`,
simplify/remove the redundant catch-all so the exception propagates naturally.
- Remove the now-unused `import traceback` where `traceback` was solely used for
`print_exc()`.
- Preserve all inner `ValueError`/`AttributeError` raises and their exact
messages.

Step 2 - Remaining files with the same pattern: Apply the identical
removal/simplification approach to
`src/hiero_sdk_python/query/topic_info_query.py`,
`src/hiero_sdk_python/query/transaction_get_receipt_query.py`,
`src/hiero_sdk_python/file/file_contents_query.py`,
`src/hiero_sdk_python/account/account_records_query.py`,
`src/hiero_sdk_python/contract/contract_bytecode_query.py`,
`src/hiero_sdk_python/contract/contract_call_query.py`,
`src/hiero_sdk_python/contract/contract_info_query.py`, and
`src/hiero_sdk_python/schedule/schedule_info_query.py`.

Do not modify docstring/example `print(...)` usages in `tokens/token_type.py`,
`tokens/fee_assessment_method.py`, and `tokens/assessed_custom_fee.py`, since
those are documentation illustrations, not runtime error handling.
===============================================================================

Task: 2

Implement Phase 2: convert `src/hiero_sdk_python/client/network.py`'s
mirror-node fallback diagnostics from direct `print(...)` calls to opt-in
logging, preserving all existing fallback control flow.

- Add `import logging` in the stdlib import group and declare a module-level
`logger = logging.getLogger(__name__)` after the imports, matching the
convention already used in `fee_estimate_query.py`/`topic_message_query.py`.
- In `_fetch_nodes_from_mirror_node`, replace `print(f"No known mirror node URL
for network='{self.network}'. Skipping fetch.")` with an equivalent
`logger.warning(...)` call.
- Replace `print(f"Error fetching nodes from mirror node API: {e}")` (inside the
`except requests.RequestException as e:` block) with an equivalent
`logger.warning(...)` call.
- Do not change the surrounding control flow: the method must still return `[]`
on failure and the caller must still fall back to default nodes via
`_resolve_nodes` exactly as before.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[iron-prog]

hey @sudo-anshul I'd like to work on this

[github-actions]

Hi @iron-prog! Thanks for your interest in contributing 💡

This issue is labeled as intermediate, which means it requires a bit more familiarity with the SDK.
Before you can take it on, please complete at least one Beginner Issue so we can make sure you have a smooth on-ramp.

You've completed 0 Beginner Issues so far.
Once you wrap up your first Beginner issue, feel free to come back and we’ll gladly help you get rolling here!