Error Handling

The SDK exposes a small hierarchy of error types so you have a single surface to catch, while still being able to distinguish validation problems from runtime failures.

Error types

Class	Thrown when
DenvigError	Base error for all SDK failures. Catch this to handle everything.
DenvigValidationError	An operation received invalid input (bad flags/options). The CLI maps these to a usage error.
DenvigOperationError	An operation failed at runtime (e.g. a service refused to start). Carries optional machine-readable details.
DenvigSDKError	The public error surface wrapping any underlying failure. Retains stderr/stdout/originalMessage for backwards compatibility.

DenvigValidationError and DenvigOperationError both extend DenvigError.

Catching errors

import {
  DenvigSDK,
  DenvigError,
  DenvigValidationError,
  DenvigOperationError,
} from '@denvig/sdk'

const denvig = new DenvigSDK({ client: 'my-app' })

try {
  const project = await denvig.projects.retrieve('github:marcqualie/denvig')
  const service = await project.services.retrieve('api')
  await service.start({ port: 3000 })
} catch (error) {
  if (error instanceof DenvigValidationError) {
    // Bad input — surface a usage hint to the user
    console.error('Invalid options:', error.message)
  } else if (error instanceof DenvigOperationError) {
    // Runtime failure — inspect machine-readable details
    console.error('Operation failed:', error.message, error.details)
  } else if (error instanceof DenvigError) {
    // Any other denvig failure
    console.error('Denvig error:', error.message)
  } else {
    throw error
  }
}

Detecting vs. retrieving

Many failures can be avoided by choosing the right resolver. projects.retrieve throws when a project can’t be resolved, whereas projects.detect returns null instead — preferable in hosts that must keep running without a project.

const { project } = await denvig.projects.detect()
if (!project) {
  // Handle the no-project case without a try/catch
}