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

> Discover why the 'error' field is set in Holehe module results. Learn about unhandled exceptions like network timeouts and API failures that trigger this status.

- Repository: [Palenath/holehe](https://github.com/megadose/holehe)
- Tags: internals
- Published: 2026-08-25

---

**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`](https://github.com/megadose/holehe/blob/main/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.

```python

# 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:

```json
{
  "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`](https://github.com/megadose/holehe/blob/main/holehe/modules/software/adobe.py)) implement specific site logic, but any unhandled exception bubbles up to the `launch_module` wrapper in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/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:**

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

```

**Failed lookup:**

```json
{
  "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`](https://github.com/megadose/holehe/blob/main/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`](https://github.com/megadose/holehe/blob/main/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`](https://github.com/megadose/holehe/blob/main/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.