---
title: Error Handling
slug: devicepark/sdk-documentation/reference/error-handling
description: Handle SDK configuration, HTTP, timeout and cleanup failures.
docTags: 
createdAt: 2026-08-10T08:03:44.631Z
---

Handle configuration, HTTP responses, transport failures and cleanup failures separately. SDK version `1.0.1` does not define an allocation-wait timeout or a fixed catalog of backend error codes.

## Failure Types

### Node.js

The package exports these SDK errors:

| Error                          | When it is used                                             | Useful fields      |
| ------------------------------ | ----------------------------------------------------------- | ------------------ |
| `DeviceParkConfigError`        | Missing client configuration or invalid SDK method argument | `message`          |
| `DeviceParkHttpError`          | Device Park returned a non-2xx response                     | `status`, `body`   |
| `DeviceParkSerializationError` | JSON serialization or parsing failed                        | `message`, `cause` |
| `DeviceParkError`              | Base class for SDK-defined errors                           | `message`, `cause` |

### Java

| Failure                                                  | Exception                                                       |
| -------------------------------------------------------- | --------------------------------------------------------------- |
| Invalid builder or method argument                       | `IllegalArgumentException`                                      |
| HTTP, authentication, network or request timeout failure | `RuntimeException` with the original `IOException` as its cause |
| Client close failure                                     | `IOException`                                                   |

### .NET

| Error                              | When it is used                                             | Useful members                                |
| ---------------------------------- | ----------------------------------------------------------- | --------------------------------------------- |
| `DeviceParkConfigException`        | Missing client configuration or invalid SDK method argument | `Message`                                     |
| `DeviceParkHttpException`          | Device Park returned a non-2xx response                     | `Status`, `ErrorCode`, `ErrorMessage`, `Body` |
| `DeviceParkSerializationException` | JSON serialization or parsing failed                        | `Message`, `InnerException`                   |
| `DeviceParkException`              | Base class for SDK-defined errors                           | `Message`                                     |

All .NET exception types live in `Testinium.DevicePark.Errors`.

## Backend Error Envelope

Device Park returns a consistent error body for failed requests:

```json
{
  "errorCode": "ALLOCATION_ERR003",
  "errorMessage": "No matching devices found for allocation",
  "errorDetails": null
}
```

The .NET SDK parses this envelope into `DeviceParkHttpException.ErrorCode` and `ErrorMessage`; both are `null` when the response does not use the envelope. `Body` always carries the raw response.

The Node.js SDK exposes the raw body through `DeviceParkHttpError.body`.

`errorDetails` is populated only for validation failures (`ERR001`), where it names the rejected field. Do not couple automation logic to specific codes without agreeing on them with the Device Park team first.

## Handle Errors

:::CodeblockTabs
```typescript
import {
  DeviceParkConfigError,
  DeviceParkHttpError,
  DeviceParkSerializationError
} from "@device-park/public-sdk";

try {
  const devices = await client.devices().list();
  console.log(devices.data);
} catch (error) {
  if (error instanceof DeviceParkConfigError) {
    console.error("Invalid SDK configuration:", error.message);
  } else if (error instanceof DeviceParkHttpError) {
    console.error("Device Park request failed:", error.status, error.body);
  } else if (error instanceof DeviceParkSerializationError) {
    console.error("Unexpected response format:", error.message);
  } else if (error instanceof Error && error.name === "AbortError") {
    console.error("Device Park request timed out");
  } else {
    throw error;
  }
}
```

```java
try {
    PageDto<Device> devices = client.devices().list(
            ListDevicesRequest.builder().build());
    devices.data().forEach(System.out::println);
} catch (IllegalArgumentException configurationError) {
    System.err.println("Invalid SDK configuration: " + configurationError.getMessage());
} catch (RuntimeException requestError) {
    System.err.println("Device Park request failed: " + requestError.getMessage());
}
```

```csharp
using Testinium.DevicePark.Errors;

try
{
    var devices = await client.Devices.ListAsync();
    Console.WriteLine(devices.Data.Count);
}
catch (DeviceParkConfigException error)
{
    Console.Error.WriteLine($"Invalid SDK configuration: {error.Message}");
}
catch (DeviceParkHttpException error)
{
    Console.Error.WriteLine($"Device Park request failed: {error.Status}");
    Console.Error.WriteLine($"{error.ErrorCode}: {error.ErrorMessage}");
}
catch (DeviceParkSerializationException error)
{
    Console.Error.WriteLine($"Unexpected response format: {error.Message}");
}
catch (TaskCanceledException)
{
    Console.Error.WriteLine("Device Park request timed out");
}
```
:::

Node.js request timeout uses `AbortController`, so a timeout surfaces as a transport-level `AbortError`. In .NET it surfaces as `TaskCanceledException` from `HttpClient.Timeout`. Neither is a `DeviceParkHttpError` / `DeviceParkHttpException`, and neither is an allocation-specific error code.

Java SDK version `1.0.1` does not expose a structured HTTP status field. If machine-readable status handling is required, agree on that behavior before coupling automation logic to exception message text.

## Allocation Waiting

Creating an allocation and waiting for a device are separate concerns. The SDK returns the allocation response; it does not keep polling until a device is assigned.

Your runner should:

1. Store `allocationId` immediately.
2. Inspect the same allocation until `deviceSerial` is assigned.
3. Apply an application-level deadline suitable for the CI job.
4. Release the allocation if the deadline is exceeded.

Do not assume a special queue-timeout exception or status code. None is defined by the public SDK contract.

:::hint{type="warning"}
Set the queue deadline in your test runner. The SDK does not poll automatically and does not throw a dedicated allocation-timeout error.
:::

## Cleanup

Cleanup order is session, allocation, client:

1. Stop every active `sessionId`.
2. Release the `allocationId` after the final session.
3. Close the client. Java uses try-with-resources, Node.js `await client.close()`, and .NET a `using` declaration.

Catch cleanup failures separately so they do not replace the original test failure. Include resource identifiers in logs, but never include credentials, access tokens or authorization headers.