Skip to content

[Refactor] Improve error handling with a structured exception hierarchy #160

Description

@Aamir377300

Problem

I’ve been working through the error handling in hiero-enterprise-base lately, and I noticed that almost every failure eventually gets swallowed up by a generic HieroException.

While that keeps things simple, it’s a bit of a headache for the end-user. If I want my app to behave differently for a "Payer Balance" issue versus a Network Timeout or a Signing Error, I currently have to resort to string-parsing exception messages. As we all know, that’s pretty fragile and breaks easily.

The Idea

I’d like to introduce a more structured exception hierarchy. The goal isn't to over-complicate things, but to give developers a way to catch specific types of failures without losing the common HieroBaseException type.

I'm thinking of something like this:

  • HieroProtocolException: Specifically for Hedera-specific status codes (like INSUFFICIENT_PAYER_BALANCE).

  • HieroSecurityException: For when things go wrong with signing or keys.

  • HieroConfigurationException: For missing providers or setup issues.

  • HieroValidationException: For pre-check and request validation failures.

Why this helps

This would make it way easier to implement clean retry logic or custom alerting on the application side. It moves the library toward being more enterprise-friendly by providing actionable errors instead of just a generic something went wrong message.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions