NOTE: Apart from
(and even then it's questionable, I'm Scottish). These are machine translated in languages I don't read. If they're terrible please contact me.
You can see how this translation was done in this article.
Friday, 13 September 2024
//Less than a minute
किसी भी वेब अनुप्रयोग में यह गलतियों को हल करने के लिए महत्वपूर्ण है. यह ख़ासकर एक उत्पादन वातावरण में सच है जहाँ आप एक अच्छे उपयोगकर्ता का अनुभव करना चाहते हैं और किसी संवेदनशील जानकारी का परदाफ़ाश नहीं करना चाहते । इस लेख में हम देखेंगे कि कैसे गलतियों को एक अनजानी में संभाल सकते हैं. कोर अनुप्रयोग.
[विषय
जब कोई अनियंत्रित अपवाद उत्पन्न होता है. अनियंत्रित कोरल अनुप्रयोग, डिफ़ॉल्ट बर्ताव 500 की स्थिति कोड के साथ जेनेरिक त्रुटि पृष्ठ लौटाना है. यह कई कारणों के लिए आदर्श नहीं है:
एक अतिरिक्त में। वहाँ एक साफ सुविधा निर्माण है जिसमें हमें इन गलतियों को नियंत्रित करने की अनुमति मिलती है।
app.UseStatusCodePagesWithReExecute("/error/{0}");
हम इसे अपने में डाल दिया Program.cs
अतुल्यकालिक स्थिति में आरंभिक फ़ाइल. यह किसी भी स्थिति कोड को पकड़ने के लिए है जो कि 200 और पुनर्निदेशित नहीं है /error
एक पैरामीटर के रूप में स्थिति कोड के साथ मार्ग.
हमारे त्रुटि नियंत्रण कुछ इस तरह दिखेगा:
[Route("/error/{statusCode}")]
public IActionResult HandleError(int statusCode)
{
// Retrieve the original request information
var statusCodeReExecuteFeature = HttpContext.Features.Get<IStatusCodeReExecuteFeature>();
if (statusCodeReExecuteFeature != null)
{
// Access the original path and query string that caused the error
var originalPath = statusCodeReExecuteFeature.OriginalPath;
var originalQueryString = statusCodeReExecuteFeature.OriginalQueryString;
// Optionally log the original URL or pass it to the view
ViewData["OriginalUrl"] = $"{originalPath}{originalQueryString}";
}
// Handle specific status codes and return corresponding views
switch (statusCode)
{
case 404:
return View("NotFound");
case 500:
return View("ServerError");
default:
return View("Error");
}
}
यह नियंत्रण त्रुटि नियंत्रण करेगा तथा स्थिति कोड पर आधारित मनपसंद दृश्य लौटाता है. हम मूल यूआरएल का लॉग कर सकते हैं जो त्रुटि पैदा करता है और इसे दृश्य में पास करता है. अगर हम एक केंद्रीय लॉगिंग / aslys सेवा था हम इस सेवा के लिए इस त्रुटि का लॉग कर सकते हैं।
हमारा दृश्य इस तरह है:
<h1>404 - Page not found</h1>
<p>Sorry that Url doesn't look valid</p>
@section Scripts {
<script>
document.addEventListener('DOMContentLoaded', function () {
if (!window.hasTracked) {
umami.track('404', { page:'@ViewData["OriginalUrl"]'});
window.hasTracked = true;
}
});
</script>
}
बहुत सरल है? हम अनुप्रयोग इंसाइट ऑन द स्क्रिप्चर्स की तरह लॉगिंग सेवा करने में भी त्रुटि का लॉग कर सकते हैं. इस तरह हम उन्हें त्रुटियों का ट्रैक रख सकते हैं और एक समस्या बनने से पहले ठीक कर सकते हैं. हमारे मामले में हम यह एक घटना के रूप में अपने उममी सेवा के लिए। इस तरह हम इस बात का ध्यान रख सकते हैं कि हमारे पास कितनी 404 त्रुटियाँ हैं और वे कहाँ से आ रहे हैं.
यह आपके चुने गए खाका और डिजाइन के अनुरूप भी रहता है ।
यह एक आसान तरीका है जिसमें त्रुटियाँ हों. NEACKT अनुप्रयोग में त्रुटिओं को नियंत्रित करने का. यह एक अच्छा उपयोगकर्ता अनुभव प्रदान करता है और हमें त्रुटियों का ट्रैक बनाए रखने देता है । यह एक लॉगिंग सेवा में गलतियों को लॉग करने के लिए एक अच्छा विचार है ताकि आप उनका ट्रैक रख सकते हैं और उन्हें एक समस्या बनने से पहले ठीक कर सकते हैं.