LessJS separates framework errors, build-time rendering errors, API errors and browser island failures. The goal is clear diagnosis without leaking internals in production.
| Kind | Examples | Response |
|---|---|---|
| Operational | not found, unauthorized, validation, rate limit | Return structured status and safe message. |
| Programming | render failure, invalid route module, broken island import | Fail build or show dev diagnostics; hide internals in production output. |
import { NotFoundError, ValidationError } from '@lessjs/core';
app.get('/api/posts/:id', async (c) => {
const post = await findPost(c.req.param('id'));
if (!post) throw new NotFoundError('Post', c.req.param('id'));
return c.json(post);
});
app.post('/api/posts', async (c) => {
const body = await c.req.json();
if (!body.title) {
throw new ValidationError('Invalid post', [
{ field: 'title', message: 'Title is required' },
]);
}
return c.json(body, 201);
});LessJS rendering errors happen during dev SSR or static generation. In development, renderSsrError() can show message and stack. In production output, errors should be safe and generic.
Renderer 2 should improve this further: failures should name the route, tag name, module path and original cause, so build logs point to the broken component instead of an empty shell.
Island failures happen in the browser after static HTML is already visible. Prefer graceful degradation: keep content readable, log the failed island, and avoid global crashes.
LessError#toJSON() returns a small structured payload. API routes can use that shape directly when adding global error middleware.
{
"error": {
"code": "VALIDATION_ERROR",
"message": "Invalid post"
}
}