Skip to main content

Introduction

Trigger test errors (404, 500) on demand to verify your error pages render correctly, and read the project's API request count.

More information about the module's user interface https://doc.oneentry.cloud/docs/category/system

🎯 What does this module do?​

The System module provides system-level utilities. It lets you test error page handling - simulate 404 and 500 errors to verify your error pages display correctly before users encounter real issues - and it exposes getApiStat() to read the project's API request count.

The error methods (test404, test500) trigger a redirect to the corresponding error page so you can confirm your error handling is implemented correctly. Use them during development and testing, not in production code.

🚀 Quickstart​

Initialize the module from defineOneEntry:


const { System } = defineOneEntry(
  "your-project-url", {
    "token": "your-app-token"
  }
);

Read the project's API request count:

// Returns an object with the API request count for the project.
const stat = await System.getApiStat();

console.log('API usage:', stat);

test404() and test500() throw on purpose to exercise your error handling, so call them inside a try/catch:

try {
  await System.test404();
} catch (error) {
  // Your 404 handling runs here.
  console.log('404 handler fired', error);
}

✨ Key Concepts​

What is the System Module?​

The System module provides testing and diagnostic utilities:

  • Error testing - Simulate 404 / 500 errors with test404() / test500()
  • Error page validation - Confirm your custom error pages render
  • API usage - Read the project's API request count with getApiStat()
  • Development tool - Use the error methods during development/testing, not in production

Error Types​

Error CodeNameWhen It OccursUse Case
404Not FoundRequested resource doesn't existPage not found, missing product
500Internal Server ErrorServer-side error occurredDatabase failure, code error

Testing Workflow​

1. Develop custom 404 and 500 pages
   ↓
2. Implement error handling (try/catch, error boundaries)
   ↓
3. Trigger errors with System.test404() / System.test500()
   ↓
4. Verify your error pages display correctly
   ↓
5. Remove the test calls before deploying to production

📋 What You Need to Know​

The error methods are for testing only​

Use test404() and test500() only during development and testing - they throw errors to exercise your handling logic. Run them in development/staging, and remove the test calls before production. Real 404/500 errors should be handled with your own try/catch and error boundaries.

Logging and monitoring are your responsibility​

The System module does not log or monitor errors. Logging and monitoring live in your own application or third-party tools - use the test methods to trigger errors so you can confirm your tracking fires.

Custom error pages are yours to build​

The module only triggers errors; you must create the custom 404 and 500 pages and the handling logic in your app.

📊 Quick Reference Table​

MethodDescriptionThrowsUse Case
test404()Simulate 404 Not Found error404 ErrorTest 404 error page
test500()Simulate 500 Server Error500 ErrorTest 500 error page
getApiStat()Get the API request count—Monitor API usage

❓ Common Questions (FAQ)​

When should I use the error methods?​

Use test404() and test500() only during development and testing to verify your error pages work correctly. Never use them in production code - they are purely a testing tool for validating error handling.

How do I test my custom error pages?​

Call System.test404() or System.test500() in your development environment, inside a try/catch. These methods throw, triggering your error handling logic so you can verify that custom error pages render correctly.

What's the difference between test404() and test500()?​

test404() simulates a "Not Found" error (resource doesn't exist), while test500() simulates an "Internal Server Error" (server-side failure). Test both to ensure all error scenarios are handled properly.

What does getApiStat() return?​

It returns an object with the project's API request count, useful for monitoring API usage.

🎓 Best Practices​

  • Use the error methods in test environments only - Never trigger test errors in production.
  • Wrap test calls in try/catch - Both test404() and test500() throw on purpose.
  • Implement custom error pages - The module only triggers errors; the pages are yours to build.
  • Verify error tracking - Use the test methods to confirm your monitoring/logging fires.
  • Remove test calls before deployment - Clean up test404() / test500() calls before production.

🔗 Related Documentation​