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
- Move all validation (typeof amount === 'number', Number.isFinite(amount), amount > 0) to the top of the function before any computation
- Add NaN and non-finite guards, since NaN <= 0 is false and NaN passes the original check
- 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
- Validate all inputs before any computation or state mutation
- Treat boundary inputs as unknown and narrow with type guards instead of trusting declared types
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.