sickn33/agentic-awesome-skills · info · Error

Invalid amount

Error message

Invalid amount

What it means

This error comes from a TypeScript snippet inside the kaizen skill documentation that demonstrates the 'validate before use' principle. processPayment throws Error('Invalid amount') when amount <= 0, but only after the fee was already computed from it. It is example code, not a shipped library function; the throw exists to teach that inputs must be validated before any computation or state change.

Source

Thrown at skills/kaizen/SKILL.md:216

// Caller must prove array is non-empty
const items: number[] = [1, 2, 3];
if (items.length > 0) {
  firstItem(items as NonEmptyArray<number>); // Safe
}
````

Function signature guarantees safety
</Good>

#### Validation Error Proofing

<Good>
```typescript
// Error: Validation after use
const processPayment = (amount: number) => {
  const fee = amount * 0.03; // Used before validation!
  if (amount <= 0) throw new Error('Invalid amount');
  // ...
};

// Good: Validate immediately
const processPayment = (amount: number) => {
if (amount <= 0) {
throw new Error('Payment amount must be positive');
}
if (amount > 10000) {
throw new Error('Payment exceeds maximum allowed');
}

const fee = amount \* 0.03;
// ... now safe to use
};

// Better: Validation at boundary with branded type
type PositiveNumber = number & { readonly \_\_brand: 'PositiveNumber' };

View on GitHub (pinned to 58d857988f)

Solutions

  1. Move all validation (typeof amount === 'number', Number.isFinite(amount), amount > 0) to the top of the function before any computation
  2. Add NaN and non-finite guards, since NaN <= 0 is false and NaN passes the original check
  3. Throw a typed/domain error instead of a bare Error so callers can branch on validation failures

Example fix

// before
const processPayment = (amount: number) => {
  const fee = amount * 0.03; // used before validation
  if (amount <= 0) throw new Error('Invalid amount');
};

// after
const processPayment = (amount: number) => {
  if (typeof amount !== 'number' || !Number.isFinite(amount) || amount <= 0) {
    throw new Error('Invalid amount');
  }
  const fee = amount * 0.03;
};
Defensive patterns

Strategy: validation

Validate before calling

function isValidAmount(a: unknown): a is number {
  return typeof a === 'number' && Number.isFinite(a) && a > 0;
}
// call before processPayment
if (!isValidAmount(input)) throw new TypeError('amount must be a positive finite number');

Type guard

function isValidAmount(a: unknown): a is number {
  return typeof a === 'number' && Number.isFinite(a) && a > 0;
}

Prevention

When it happens

Trigger: Calling the example processPayment(amount) with amount <= 0 (e.g. processPayment(0) or processPayment(-5)), or passing NaN, which slips past the amount <= 0 check while the already-computed fee is NaN.

Common situations: Developers copying the teaching snippet into real payment code without adding NaN/non-finite/type checks; validating only after logging, persisting, or computing with the amount; test fixtures using 0 or negative amounts.

Related errors


AI-assisted analysis of sickn33/agentic-awesome-skills@58d857988f (2026-08-26). Data as JSON: /api/errors/14c3146686d137d1. Report an issue: GitHub.