Safe Array Item Access
Prevents index out-of-bounds errors when accessing array elements, returns default value for invalid indices
Implementation
Copy the complete example or adapt its typed interface to your project. Comments are kept inside the snippet so the intent travels with the code.
/**
* Safe array item access (prevents out-of-bounds errors)
* @param arr Target array
* @param index Target index
* @param defaultValue Default value for invalid indices
* @returns Value at index or default value
*/
function getArrayItem<T>(arr: T[], index: number, defaultValue: T): T {
return index >= 0 && index < arr.length ? arr[index] : defaultValue;
}
// Usage Example
console.log(getArrayItem([1, 2, 3], 5, 0)); // 0
console.log(getArrayItem([1, 2, 3], 1, 0)); // 2When to use it
Essential for accessing array elements with uncertain indices (e.g., dynamic data, user input-based indexing)
Review the input assumptions and browser or runtime support before adopting a utility unchanged. Small helpers are easiest to maintain when their contract stays narrow.
Reasoning and trade-offs
How it works
The helper checks that the requested index falls inside the array and returns a caller-provided fallback when it does not. This centralizes a boundary rule that would otherwise be repeated at every access site.
What to watch for
A valid array element can itself be undefined, which is different from an invalid index unless the project chooses to treat them alike. Negative indexing is not supported here, and fractional or NaN indices should be rejected deliberately.
Production use
Use safe access when consuming user-selected positions, paginated results, or optional configuration arrays. If absence is meaningful, returning undefined or a Result-style value is often clearer than silently substituting a default.
Before you ship
- Confirm the input contract with tests that cover empty, invalid, boundary, and representative real-world values before sharing the helper across a codebase.
- Keep the function focused on one responsibility and name any project-specific policy explicitly instead of hiding it inside a generic-looking utility.
- Measure behavior in the browsers or runtime versions your product supports, especially when timing, storage, DOM state, locale, or network access is involved.
- Document the return type, mutation behavior, failure mode, and performance characteristics beside the call site so future maintainers can evaluate changes safely.
- Compare the example with current official platform documentation when it relies on a browser API, language feature, or runtime behavior that may change over time.
- If the helper crosses a trust boundary, validate again on the server and avoid treating browser-side checks, TypeScript annotations, or formatted output as a security guarantee.
- Add a small regression test whenever a real edge case is discovered; concrete examples preserve the reason behind a guard more reliably than a general comment.