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

The problem with untested error pages:

// ❌ Bad - Never tested error pages
// What if 404 page is broken?
// What if 500 page doesn't render?
// Users see ugly default error pages!

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:

// ✅ Good - Test error pages
try {
await System.test404();
// Verifies 404 page renders correctly
} catch (error) {
console.log('404 page works!');
}

try {
await System.test500();
// Verifies 500 page renders correctly
} catch (error) {
console.log('500 page works!');
}

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

1. System Module is for Testing Only

Important: Use System module only during development and testing.

// ✅ Good - Development/testing environment
if (process.env.NODE_ENV === 'development') {
await System.test404();
}

// ❌ Bad - Production environment
// NEVER trigger test errors in production!
await System.test404();

Why?

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

2. Error Testing Best Practices

Test error pages during development

3. Custom Error Pages

Create custom error pages for better UX

4. Error Logging and Monitoring

Implement error tracking


📊 Quick Reference Table

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

Error Structure:

interface SystemError {
status: number; // 404 or 500
message: string; // Error message
statusText: string; // "Not Found" or "Internal Server Error"
}

Usage Pattern:

try {
await System.test404(); // or test500()
} catch (error) {
// error.status = 404
// error.message = "Not Found"
// Handle error
}

💡 Important Notes

⚠️ Development Tool Only

Remember: System module is for testing, not production.

Do NOT use in production:

// ❌ NEVER do this in production
app.get('/api/data', async (req, res) => {
await System.test500(); // BAD!
});

Use only in tests:

// ✅ Good - Test environment
if (process.env.NODE_ENV === 'test') {
await System.test404();
}

🔍 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:

// You need to implement:
// 1. Custom 404 page component
// 2. Custom 500 page component
// 3. Error boundary component
// 4. Error handling logic

// System module just helps test these

📊 Error Monitoring Integration

Integrate with monitoring services:

  • Sentry
  • LogRocket
  • New Relic
  • Custom logging
try {
await System.test404();
} catch (error) {
// Send to Sentry
Sentry.captureException(error);
}

🎓 Best Practices

✅ DO:

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

❌ DON'T:

  1. Don't use in production - Only for testing
  2. Don't rely only on default errors - Create custom pages
  3. Don't skip error testing - Verify pages work
  4. Don't forget error logging - Track issues
  5. Don't expose error details - Security risk
  6. Don't ignore error UX - Poor experience
  7. Don't test in live code - Use test suites
  8. Don't forget to remove tests - Clean before deploy

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.

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


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