Skip to main content

Introduction

🎯 What does this module do?​

The System module lets you test error page handling - simulate 404 and 500 errors to verify your error pages display correctly, helping you ensure proper error handling before users encounter real issues.

Think of it as your error testing tool - trigger test errors on demand, verify error pages render properly, and ensure your error handling logic works as expected without breaking production.

📖 Simple Explanation​

Every application needs proper error handling:

  • 🔍 404 Not Found - Page doesn't exist
  • 💥 500 Server Error - Internal server failure
  • 🎨 Custom Error Pages - Branded error experience
  • 🔄 Error Logging - Track error occurrences
  • 📊 Error Monitoring - Detect issues early
  • ✅ Error Testing - Verify error pages work

Issues:

  • 🔍 No validation - Error pages might be broken
  • 🎨 Poor UX - Ugly default error pages
  • 🔄 No tracking - Don't know when errors occur
  • 📊 No monitoring - Can't detect issues

The System solution:

Benefits:

  • 🔍 Validated - Know error pages work
  • 🎨 Better UX - Custom branded error pages
  • 🔄 Tracked - Log error occurrences
  • 📊 Monitored - Detect issues early

✨ Key Concepts​

What is the System Module?​

The System module provides testing utilities:

  • Error Testing - Simulate 404/500 errors
  • Error Page Validation - Verify error pages render
  • Error Handling Verification - Test error logic
  • Development Tool - Use during development/testing
  • Not for Production - Don't use in live code

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 error pages
   (Custom 404 and 500 pages)
   ↓
2. Implement error handling
   (Try/catch, error boundaries)
   ↓
3. Test with System module
   (System.test404(), System.test500())
   ↓
4. Verify error pages display
   (Check UI, logging, tracking)
   ↓
5. Deploy with confidence
   (Know error handling works)

Why Use System Module?​

BenefitDescription
Error ValidationTest error pages before users see them
Development ToolTrigger errors on demand
Error Logic TestingVerify error handling code
Custom Error PagesEnsure branded error experience
Early DetectionCatch issues before production

📋 What You Need to Know​

System Module is for Testing Only​

Important: Use System module only during development and testing.

Why?

  • Test errors should not reach real users
  • Use only in development/staging environments
  • Remove test code before production deployment

Error Testing Best Practices​

Test error pages during development

Custom Error Pages​

Create custom error pages for better UX

Error Logging and Monitoring​

Implement error tracking

💡 Important Notes​

Development Tool Only​

Remember: System module is for testing, not production.

Error Testing vs Real Errors​

System errors are simulated:

  • Test errors don't affect real users
  • Use to verify error handling logic
  • Remove before production deployment

Real errors occur naturally:

  • Actual 404: Page not found
  • Actual 500: Server failure
  • Handle with try/catch and error boundaries

Custom Error Pages Required​

System module only triggers errors - you must create error pages

📊 Quick Reference Table​

MethodDescriptionThrowsUse Case
test404()Simulate 404 Not Found error404 ErrorTest 404 error page
test500()Simulate 500 Server Error500 ErrorTest 500 error page

❓ Common Questions (FAQ)​

When should I use the System module?​

Use the System module only during development and testing to verify your error pages work correctly. Never use it in production code - it's 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. These methods throw errors that trigger your error handling logic, allowing you to 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.

Can I use the System module in production?​

No! The System module is strictly for development and testing. Remove all System module test calls before deploying to production. Use real error handling (try/catch, error boundaries) for production errors.

How do I create custom error pages?​

Create dedicated error page components for 404 and 500 errors in your application. Use error boundaries (React) or equivalent error handling in your framework to catch errors and display these custom pages.

Should I log errors triggered by the System module?​

Yes, logging test errors helps verify your error tracking and monitoring systems work correctly. However, clearly mark them as test errors to avoid confusion with real production issues.

🎓 Best Practices​

  • Test error pages during development - Verify they render correctly
  • Use in test environment only - Never in production
  • Implement custom error pages - Better UX than default errors
  • Log errors for debugging - Track what went wrong
  • Test error boundaries - React/Vue error handling
  • Verify error tracking - Ensure monitoring works
  • Remove test code - Clean up before deployment
  • Document error handling - Help team understand flow

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

Definition of the System module​

The System module in OneEntry Platform provides methods for testing error page redirections, allowing developers to ensure that their error handling mechanisms are functioning correctly. By using the defineOneEntry function, you can create a System object to access these functionalities. The module offers two primary methods: test404 and test500. Both methods simulate scenarios where the user is redirected to an error page, specifically 404 (Not Found) and 500 (Internal Server Error) pages, respectively. These tools are essential for verifying that the system's error pages are correctly implemented and displayed to users when needed.


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

🔗 Related Documentation​