What Causes the 'error' Field to Be Set in Holehe Module Results

The error field is set to True in Holehe module results only when a module raises an unhandled exception during execution, such as a network timeout, connection failure, or unexpected API response.

Holehe is an open-source OSINT tool that verifies whether an email address is registered across hundreds of online services. When analyzing output from the megadose/holehe repository, the Boolean error field serves as a critical discriminator between a successfully completed lookup and a failed module execution that requires retry or investigation.

Exception Handling in the Core Launcher

The exception handling logic resides in holehe/core.py within the launch_module wrapper function (approximately lines 168-176). This async function wraps every module call to ensure that catastrophic failures in individual service checks do not crash the entire batch operation.

When a module executes successfully, it appends its own result dictionary to the shared out list with error explicitly set to False or omitted entirely. However, if the module function throws any unhandled Exception, the wrapper catches it and injects a standardized error result.

# From holehe/core.py – the launch_module wrapper

async def launch_module(module, email, client, out):
    try:
        await module(email, client, out)               # Normal execution path

    except Exception:
        name = str(module).split('<function ')[1].split(' ')[0]
        out.append({
            "name": name,
            "domain": data[name],
            "rateLimit": False,
            "error": True,          # <-- Set exclusively on exception

            "exists": False,
            "emailrecovery": None,
            "phoneNumber": None,
            "others": None,
        })

Structure of Error Results

When the launch_module wrapper catches an exception, it appends a dictionary with specific default values that indicate the failure state. Unlike successful results that may contain parsed account data, error results follow a nullified pattern:

{
  "name": "adobe",
  "domain": "adobe.com",
  "rateLimit": false,
  "error": true,
  "exists": false,
  "emailrecovery": null,
  "phoneNumber": null,
  "others": null
}

Key fields in error states:

• error: true – Indicates the module encountered an unhandled exception and could not complete its verification logic.
• rateLimit: false – Remains false in basic exception scenarios, though the field exists to distinguish rate-limiting responses from other errors.
• exists: false – Defaults to false because the tool cannot confirm existence when the check fails.
• Recovery fields – All set to null since no data could be extracted.

Common Triggers for the Error Field

According to the implementation in megadose/holehe, the error field becomes True specifically when modules encounter runtime exceptions rather than logical negative results. Common scenarios include:

• Network timeouts when a service fails to respond within the allocated timeframe
• Connection errors due to DNS failures, SSL handshake issues, or firewall blocks
• Parsing failures when a website returns unexpected HTML structure or malformed JSON
• HTTP client errors raised by the underlying httpx or aiohttp session

Modules located in holehe/modules/* (such as holehe/modules/software/adobe.py) implement specific site logic, but any unhandled exception bubbles up to the launch_module wrapper in holehe/core.py, which then standardizes the error response.

Distinguishing Errors from Negative Results

Understanding the error field prevents misinterpreting failed lookups as confirmed account absences. When Holehe successfully queries a service and determines an email is not registered, the module returns error: false alongside exists: false.

Successful negative result:

{
  "name": "example_service",
  "domain": "example.com",
  "error": false,
  "exists": false
}

Failed lookup:

{
  "name": "example_service",
  "domain": "example.com",
  "error": true,
  "exists": false
}

The presence of error: true always indicates that the module could not complete its verification due to technical failure, not that the target email is necessarily absent from the service.

Summary

• The launch_module function in holehe/core.py catches all unhandled exceptions from individual modules and standardizes error responses.
• The error field is Boolean and defaults to True only within the exception handler, specifically when network issues, timeouts, or parsing errors occur.
• Successful module execution results in error: false (or the field omitted), while error: true indicates the check failed to complete.
• Error results contain null values for emailrecovery, phoneNumber, and others fields, distinguishing them from valid negative responses.
• Individual modules in holehe/modules/* do not set the error flag themselves; the core wrapper manages this state centrally.

Frequently Asked Questions

What does "error": true mean in Holehe JSON output?

The error: true value indicates that the module encountered an unhandled exception during execution—such as a network timeout, connection refusal, or HTML parsing error—and could not determine whether the email exists on that service. It does not confirm the email is unregistered; rather, it signals a technical failure requiring investigation or retry.

How is the error field different from the rateLimit field in Holehe results?

While both are Boolean fields in the result dictionary, error indicates a general execution failure (network, parsing, or unexpected exception), whereas rateLimit specifically flags when a service has blocked the request due to too many attempts. According to the launch_module implementation in holehe/core.py, these fields can coexist, but error: true typically accompanies infrastructure failures rather than rate-limiting responses.

Where is the exception handling logic implemented in the Holehe codebase?

The central exception handling logic resides in holehe/core.py within the launch_module async function. This wrapper catches exceptions raised by any module in the holehe/modules/ directory and appends the standardized error result to the output list.

Does error: true indicate that the email does not exist on the service?

No. The error: true state explicitly means the check could not complete, not that the account was verified as absent. When Holehe successfully queries a service and finds no account, it returns error: false with exists: false. An error state requires manual verification or retry, as the tool failed to reach a definitive conclusion.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}