Handling errors

Robust document pipelines treat failures as data: a corrupt input, a missing file, or an unsupported feature must surface as a structured error your application can log and act on — not as a crash. This guide shows the SDK’s error handling pattern with a PDF conversion example.

Handle SDK errors with the .NET SDK

Every SDK method throws a NutrientException on failure. The exception carries the SDK error code, message, and error type, so a single try/catch around the document workflow captures everything.

Validate the input

Check preconditions your application owns — like the input file existing — before calling the SDK:

using Nutrient;

const string inputFile = "input.pdf";
const string outputFile = "output.pdf";

if (!File.Exists(inputFile))
{
    Console.Error.WriteLine($"Error: Input file '{inputFile}' not found.");
    Environment.Exit(1);
}

Wrap the SDK workflow

Run the document operations inside try/catch; the using statement releases the native handle even when a step fails:

Console.WriteLine($"Opening document: {inputFile}");

try
{
    using Document document = Document.Open(inputFile);
    Console.WriteLine("Document opened successfully.");
    Console.WriteLine("Converting to PDF...");
    document.ExportAsPdf(outputFile);
    Console.WriteLine($"Successfully converted to {outputFile}");
}
catch (NutrientException e)
{
    Console.Error.WriteLine($"Nutrient SDK Error: {e.Message}");
    Environment.Exit(1);
}

Inspect the exception

NutrientException exposes Code (the numeric SDK error code), Message, and ErrorType (the originating SDK error class). Log all three when reporting failures — the code and type pin down the exact failure without reproducing it.

Conclusion

With one try/catch and a using statement around the workflow, every SDK failure surfaces as a structured, loggable error and the native resources are always released.