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 Code | Name | When It Occurs | Use Case |
|---|---|---|---|
| 404 | Not Found | Requested resource doesn't exist | Page not found, missing product |
| 500 | Internal Server Error | Server-side error occurred | Database 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?
| Benefit | Description |
|---|---|
| Error Validation | Test error pages before users see them |
| Development Tool | Trigger errors on demand |
| Error Logic Testing | Verify error handling code |
| Custom Error Pages | Ensure branded error experience |
| Early Detection | Catch 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
| Method | Description | Throws | Use Case |
|---|---|---|---|
test404() | Simulate 404 Not Found error | 404 Error | Test 404 error page |
test500() | Simulate 500 Server Error | 500 Error | Test 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:
- 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
❌ DON'T:
- Don't use in production - Only for testing
- Don't rely only on default errors - Create custom pages
- Don't skip error testing - Verify pages work
- Don't forget error logging - Track issues
- Don't expose error details - Security risk
- Don't ignore error UX - Poor experience
- Don't test in live code - Use test suites
- 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" });