arkyn
ChangelogGuides
docs / bad-responses / not-implemented

NotImplemented

The NotImplemented class represents an HTTP error response with status code 501. It is used to standardize "Not Implemented" error responses, typically when a requested feature or functionality has not been developed yet.

Import

ts

import { NotImplemented } from "@arkyn/server/notImplemented";
Learn how subpath and root imports differ in How do I use imports.

Constructor

  • message (required): A descriptive message explaining why the feature is not implemented.
  • cause (optional): Additional information about the error cause, which can be any serializable data.

Methods

toResponse() - Converts the instance into a Response object with JSON body and Content-Type: application/json header.
toJson() - Alternative method using Response.json() for generating the JSON error response.

Usage example

typescript

import { NotImplemented } from "@arkyn/server/notImplemented";


// Basic usage - throw the error
throw new NotImplemented("This feature is coming soon");


// With cause information
throw new NotImplemented("Payment method not supported yet", {
    requestedMethod: "crypto",
    availableMethods: ["credit_card", "pix"],
});


// Convert to Response object
const error = new NotImplemented("Export to PDF is not available");
return error.toResponse();


// Using toJson alternative
return error.toJson();

Response structure

The response body follows a standardized structure:

json

{
    "name": "NotImplemented",
    "message": "This feature is coming soon"
}
This is sent with HTTP status 501, set on the Response object itself, the status code is not part of the JSON body.
If a cause is passed to the constructor, it is included in the body as well:

json

{
    "name": "NotImplemented",
    "message": "Payment method not supported yet",
    "cause": { "requestedMethod": "crypto", "availableMethods": ["credit_card", "pix"] }
}

Notes

When thrown, this class automatically emits a debug log to the console showing the file and function where the error originated. See DebugService to configure ignored files for accurate caller detection.
The cause parameter, when provided, is included in the response body under the cause key as-is, it is sent to clients, not just kept for server-side debugging. Since v3.0.12, cause is no longer serialized with JSON.stringify() first, it's stored and returned exactly as passed (an object stays a nested object, not a JSON-encoded string). See Breaking Changes.
Since v3.0.10, cause is omitted from the response body entirely when NODE_ENV === "production", to avoid leaking internal error detail to clients. message and name are unaffected in every environment. See Breaking Changes.
Common use cases include placeholder endpoints, planned features, unsupported HTTP methods, and functionality under development.
Related in Bad responses
On this page
    arkyn