একাধিক স্তরযুক্ত আর্কিটেকচার: আমার ত্রুটি লগিং-হ্যান্ডলিং কোথায় কার্যকর করা উচিত?

আমি বর্তমানে একটি বহু স্তরযুক্ত আর্কিটেকচারের সাথে একটি বৃহত সাবসিস্টেম রিফ্যাক্টর করছি এবং আমি কার্যকর ত্রুটি লগিং-হ্যান্ডলিংয়ের কৌশলটি ডিজাইনের জন্য সংগ্রাম করছি।

ধরা যাক যে আমার স্থাপত্যে নিম্নলিখিত তিনটি স্তর রয়েছে:

পাবলিক ইন্টারফেস (IE একটি এমভিসি নিয়ন্ত্রক)
ডোমেন স্তর
ডেটা অ্যাক্সেস লেয়ার

আমার বিভ্রান্তির উত্স হ'ল যেখানে ত্রুটি লগিং-হ্যান্ডলিংয়ের প্রয়োগ করা উচিত:

সবচেয়ে সহজ সমাধানটি হবে শীর্ষ স্তরের লগিং বাস্তবায়ন (IE পাবলিক ইন্টারফেস \ এমভিসি কন্ট্রোলার)। তবে এটি ভুল অনুভব করে কারণ এর অর্থ ভিন্ন স্তরগুলির ব্যতিক্রমকে বুবলি করা এবং তারপরে এটি লগ করা; পরিবর্তে এটি উত্স লগ ইন।
এটির উত্সটিতে ব্যতিক্রমটি লগইন করা স্পষ্টতই সেরা সমাধান কারণ আমার কাছে সর্বাধিক তথ্য রয়েছে। এর সাথে আমার সমস্যাটি হ'ল আমি সমস্ত ব্যাতিক্রম না ধরে উত্সের প্রতিটি ব্যতিক্রম ধরতে পারি না এবং ডোমেন / পাবলিক ইন্টারফেস স্তরে এটি ইতিমধ্যে নীচে থাকা স্তরের দ্বারা ধরা পড়া, লগইন করা এবং পুনরায় ছুঁড়ে ফেলা ব্যতিক্রমগুলি ধরার দিকে পরিচালিত করবে ।
আর একটি সম্ভাব্য কৌশল হ'ল # 1 এবং # 2 এর মিশ্রণ; যার মাধ্যমে আমি স্তরে নির্দিষ্ট ব্যতিক্রমগুলি ধরি সেগুলি সম্ভবত ছুঁড়ে ফেলার সম্ভাবনা রয়েছে (IE ক্যাচিং, লগিং এবং SqlExceptionsডেটা অ্যাক্সেস লেয়ারে পুনরায় নিক্ষেপ ) এবং তারপরে উপরের স্তরের আরও কিছু ব্যাতিক্রম ব্যতিক্রম লগ করুন। তবে এটির জন্য আমারও শীর্ষ স্তরের প্রতিটি ব্যতিক্রম ধরা এবং পুনর্বিবেচনার প্রয়োজন হবে, কারণ আমি ইতিমধ্যে লগ হওয়া ত্রুটিগুলির মধ্যে পার্থক্য করতে পারি না vs যেগুলি নেই তার বিপরীতে পরিচালিত।

এখন, বেশিরভাগ সফ্টওয়্যার অ্যাপ্লিকেশনগুলিতে অবশ্যই এটি একটি সমস্যা, সুতরাং অবশ্যই এই সমস্যার একটি স্ট্যান্ডার্ড সমাধান থাকতে হবে যার ফলে ব্যতিক্রমগুলি উত্সটিতে ধরা পড়ে এবং একবার লগ হয়; তবে আমি নিজেই এটি কীভাবে করব তা দেখতে পাচ্ছি না।

দ্রষ্টব্য, এই প্রশ্নের শিরোনামটি ' বহু স্তরের অ্যাপ্লিকেশনটিতে লগিং ব্যতিক্রমগুলি "" এর সাথে খুব মিল , তবে এই পোস্টের উত্তরগুলির বিশদই নেই এবং আমার প্রশ্নের উত্তর দেওয়ার পক্ষে যথেষ্ট নয়।

design error-handling

— KidCode
সূত্র

আমি কখনও কখনও ব্যবহার করি এমন একটি দৃষ্টিভঙ্গি হ'ল আমার নিজস্ব ব্যতিক্রম (বা রানটাইমএক্সেপশন) সাবক্লাস তৈরি করা এবং এটি একটি নেস্টেড হিসাবে মূল ব্যতিক্রম সহ নিক্ষেপ করা। অবশ্যই এটির অর্থ হ'ল উচ্চ স্তরের ব্যতিক্রমগুলি ক্যাপচার করার সময় আমার ব্যতিক্রমের ধরণটি পরীক্ষা করা দরকার (আমার নিজস্ব ব্যতিক্রমগুলি পুনরায় নতুনভাবে পুনরায় প্রতিষ্ঠিত হয়, অন্যান্য ব্যতিক্রমগুলি লগ হয় এবং আমার ব্যতিক্রমগুলির নতুন উদাহরণগুলিতে অন্তর্ভুক্ত হয়)। তবে আমি দীর্ঘদিন ধরে একক কাজ করে যাচ্ছি তাই আমি "অফিসিয়াল" পরামর্শ দিতে পারি না।

— এসজুয়ান 76

The easiest solution would be to implement the logging at the top level- এটা কর. তাদের উত্সে ব্যতিক্রমগুলি লগইন করা ভাল ধারণা নয় এবং আমি যে সমস্ত অ্যাপ্লিকেশনটির মুখোমুখি হয়েছি তা এটি ডিবাগ করার জন্য পিআইটিএ ছিল। ব্যতিক্রমগুলি পরিচালনা করার জন্য কলারের দায়িত্ব হওয়া উচিত।

— জাস্টিন

আপনার মনে হয় কিছু নির্দিষ্ট প্রয়োগের কৌশল / ভাষা মনে আছে, অন্যথায় আপনার বিবৃতি "লগ করা হয়েছে এমন ব্যতিক্রমগুলি যেগুলি ছিল না সেগুলি থেকে অনাদায়ী" এটি বোঝা শক্ত hard আপনি আরও প্রসঙ্গ দিতে পারেন?

— ভুরফোনডেল

@ রুমফন্ডেল - আপনি ঠিক বলেছেন। আমি সি # ব্যবহার করছি এবং try{ ... } catch(Exception ex) { Log(ex); }প্রতিটি লেয়ারে কোড মোড়ানো দিয়ে প্রতিটি স্তরে একই ব্যতিক্রম লগ করা হবে। (কোড বেসের প্রতিটি স্তরে প্রতিটি ব্যতিক্রম

— ধরাও

উত্তর:

আপনার প্রশ্নের উত্তর:

সবচেয়ে সহজ সমাধান হ'ল শীর্ষ স্তরে লগিং বাস্তবায়ন করা

শীর্ষ স্তরের ব্যতিক্রম বুদবুদ হওয়া একটি একেবারে সঠিক এবং বিশ্বাসযোগ্য পদ্ধতির। উচ্চ স্তরের কোনওটিই ব্যর্থতার পরে কিছু প্রক্রিয়া চালিয়ে যাওয়ার চেষ্টা করে না, যা সাধারণত সফল হতে পারে না। এবং একটি সুসজ্জিত ব্যতিক্রম লগিংয়ের জন্য প্রয়োজনীয় সমস্ত তথ্য ধারণ করে। এবং ব্যতিক্রম সম্পর্কে কিছুই না করা আপনাকে ব্যর্থতার পরিবর্তে আপনার কোডটি পরিষ্কার রাখতে এবং মূল কাজে মনোনিবেশ করতে সহায়তা করে।

এটির উত্সটিতে ব্যতিক্রমটি লগইন করা স্পষ্টতই সেরা সমাধান কারণ আমার কাছে সর্বাধিক তথ্য রয়েছে।

এটা অর্ধেক সঠিক। হ্যাঁ, বেশিরভাগ দরকারী তথ্য সেখানে পাওয়া যায়। তবে আমি অবিলম্বে এটি লগ করার পরিবর্তে ব্যতিক্রমী অবজেক্টে (যদি এটি ইতিমধ্যে উপস্থিত না থাকে) সমস্ত কিছু দেওয়ার পরামর্শ দিই। আপনি যদি নিম্ন স্তরে লগইন করেন, আপনার কলকারীদের বলার জন্য যে আপনি আপনার কাজটি পুরোপুরি সম্পন্ন করেননি আপনাকে এখনও একটি ব্যতিক্রম ছুঁড়ে ফেলতে হবে। এটি একই ইভেন্টের একাধিক লগে শেষ হয়।

ব্যতিক্রমসমূহ

আমার মূল নির্দেশিকাটি কেবল শীর্ষ স্তরে ব্যতিক্রমগুলি ধরা এবং লগ করা। এবং নীচের সমস্ত স্তরগুলির অবশ্যই নিশ্চিত করা উচিত যে সমস্ত প্রয়োজনীয় ব্যর্থতার তথ্য শীর্ষ স্তরে স্থানান্তরিত হয়। একক প্রক্রিয়া প্রয়োগের মধ্যে যেমন জাভাতে, এর বেশিরভাগটি অর্থ শীর্ষ স্তরের বাইরে মোটেও চেষ্টা / ধরা বা লগ না করা।

কখনও কখনও, আপনি ব্যতিক্রম লগের অন্তর্ভুক্ত কিছু প্রসঙ্গের তথ্য চান যা মূল ব্যতিক্রম নয়, যেমন এসকিউএল বিবৃতি এবং পরামিতিগুলি ব্যতিক্রম ছোঁড়ার সময় কার্যকর করা হয়েছিল। তারপরে আপনি আসল ব্যতিক্রমটি ধরতে পারেন এবং একটি নতুনটিকে আবার ফেলে দিতে পারেন, মূলটি সহ প্রসঙ্গে containing

অবশ্যই, বাস্তব জীবনে কখনও কখনও হস্তক্ষেপ হয়:

জাভাতে, কখনও কখনও আপনাকে কোনও ব্যতিক্রম ধরা হয় এবং কিছু নির্দিষ্ট পদ্ধতির স্বাক্ষরগুলি মেনে চলার জন্য এটি একটি আলাদা ব্যতিক্রম প্রকারে আবদ্ধ করতে হয়। তবে আপনি যদি কোনও ব্যতিক্রম পুনরায় নিক্ষেপ করেন তবে নিশ্চিত হয়ে নিন যে পুনরায় নিক্ষেপ করা একটিতে পরবর্তী লগিংয়ের জন্য প্রয়োজনীয় সমস্ত তথ্য রয়েছে।
যদি আপনি একটি আন্ত-প্রক্রিয়া সীমানা অতিক্রম করে থাকেন তবে প্রায়শই আপনি প্রযুক্তিগতভাবে স্ট্যাক ট্রেস সহ সম্পূর্ণ ব্যতিক্রম স্থানটি স্থানান্তর করতে পারবেন না। এবং অবশ্যই সংযোগটি হারিয়ে যেতে পারে। সুতরাং এখানে একটি বিষয় যেখানে কোনও পরিষেবার ব্যতিক্রমগুলি লগ করতে হবে এবং তারপরে লাইন জুড়ে যতটা সম্ভব ব্যর্থতার তথ্য তার ক্লায়েন্টের কাছে প্রেরণের জন্য যথাসাধ্য চেষ্টা করা উচিত। পরিষেবাটি অবশ্যই নিশ্চিত করতে হবে যে ক্লায়েন্ট একটি ব্যর্থতার নোটিশ পেয়েছে, হয় ব্যর্থতার প্রতিক্রিয়া গ্রহণ করে অথবা কোনও ভাঙ্গা সংযোগের ক্ষেত্রে টাইমআউট চালিয়ে। এটি সাধারণত একইভাবে দুবার লগ ইন করার ব্যর্থতার ফলে, একবার পরিষেবার ভিতরে (আরও বিশদ সহ) এবং একবার ক্লায়েন্টের শীর্ষ স্তরে আসবে।

লগিং

আমি সাধারণভাবে লগিং সম্পর্কে কিছু বাক্য যুক্ত করছি, কেবল ব্যতিক্রম-লগিং নয়।

ব্যতিক্রমী পরিস্থিতিগুলি ছাড়াও, আপনি চাইলে আপনার অ্যাপ্লিকেশনটির গুরুত্বপূর্ণ ক্রিয়াকলাপ লগের মধ্যেও রেকর্ড করা হোক। সুতরাং, একটি লগিং ফ্রেমওয়ার্ক ব্যবহার করুন।

লগ স্তরগুলি সম্পর্কে সতর্কতা অবলম্বন করুন (লগগুলি পড়ুন যেখানে ডিবাগ তথ্য এবং গুরুতর ত্রুটিগুলি সেই অনুযায়ী আলাদাভাবে পতাকাঙ্কিত করা হয় না এটি একটি ব্যথা!)। সাধারণ লগ স্তরগুলি হল:

ত্রুটি: কিছু ফাংশন অপরিশোধিতভাবে ব্যর্থ হয়েছে। এর অর্থ এই নয় যে আপনার পুরো প্রোগ্রামটি ক্র্যাশ হয়েছে, তবে কিছু কাজ শেষ করা যায়নি। সাধারণত, আপনার ব্যর্থতা বর্ণনা করে এমন একটি ব্যতিক্রমী অবজেক্ট রয়েছে।
সতর্কতা: অদ্ভুত কিছু ঘটেছে, তবে কোনও কাজ ব্যর্থ হওয়ার কারণ ঘটেনি (অদ্ভুত কনফিগারেশন সনাক্ত হয়েছে, অস্থায়ী সংযোগ বিচ্ছিন্ন হয়ে যাওয়ার ফলে কিছু পুনরায় চেষ্টা করা হবে ইত্যাদি)
ইনফো: আপনি স্থানীয় সিস্টেম প্রশাসকের কাছে কিছু গুরুত্বপূর্ণ প্রোগ্রাম ক্রিয়াকলাপটি যোগাযোগ করতে চান (এর কনফিগারেশন এবং সফ্টওয়্যার সংস্করণ দিয়ে কিছু পরিষেবা শুরু করা, ডাটাবেসে ডেটা ফাইল আমদানি করা, ব্যবহারকারীরা সিস্টেমে লগইন করুন, আপনি ধারণাটি পাবেন ...)।
ডিবাগ: আপনি যখন কোনও সমস্যা ডিবাগ করছেন তখন বিকাশকারী হিসাবে আপনি যে জিনিসগুলি দেখতে চান তা (তবে আপনি কখনই এই বা সেই নির্দিষ্ট বাগের ক্ষেত্রে আপনার কী প্রয়োজন তা আগেই কখনই জানতে পারবেন না - যদি আপনি এটি আগে থেকেই দেখতে পারেন তবে আপনি বাগটি ঠিক করে ফেলবেন )। একটি জিনিস যা সর্বদা কার্যকর হয় তা হ'ল বাহ্যিক ইন্টারফেসে ক্রিয়াকলাপগুলি লগ করা।

উত্পাদনে, লগ স্তর INFO এ সেট করুন। ফলাফলগুলি কোনও সিস্টেম প্রশাসকের পক্ষে কার্যকর হওয়া উচিত তাই তিনি জানেন যে কী চলছে। লগের প্রতিটি ত্রুটি এবং সতর্কতার অর্ধেকের জন্য আপনাকে সহায়তা বা বাগ-ফিক্সিংয়ের জন্য ডাকবেন বলে আশা করুন।

কেবল সত্য ডিবাগিং সেশনের সময়ই DEBUG স্তর সক্ষম করুন।

আপনার বিভাগের নির্দিষ্ট অংশগুলির জন্য ডিবাগ লগগুলিতে স্যুইচ করার অনুমতি দিয়ে যথাযথ বিভাগগুলিতে লগ এন্ট্রিগুলি গোষ্ঠীভুক্ত করুন (উদাহরণস্বরূপ যে এন্ট্রিটি উত্পন্ন করে এমন কোডের সম্পূর্ণ-যোগ্যতাসম্পন্ন শ্রেণীর নাম অনুসারে)।

— রালফ ক্লেবারহফ off
সূত্র

এই ধরনের একটি উত্তরের জন্য ধন্যবাদ, আমি সত্যিই খুব লগিং অংশ প্রশংসা।

— কিডকোড

-1

আমি নীচের জনগোষ্ঠীর জন্য নিজেকে আঁকছি, কিন্তু আমি একটি অঙ্গ নিয়ে বেরিয়ে যাচ্ছি এবং বলব যে আমি এর সাথে একমত হতে পারি তা আমি নিশ্চিত নই।

বুবলিং ব্যতিক্রম আপ, তাদের আবার খুব কম লগ ইন করা, সামান্য সুবিধা দিয়ে অতিরিক্ত প্রচেষ্টা। উত্সটিতে ব্যতিক্রমটি ধরুন (হ্যাঁ, সবচেয়ে সহজ), লগ করুন তবে তারপরে ব্যতিক্রমটিকে আবার ফেলে দেবেন না, কেবল কলকারীকে "ত্রুটি" হিসাবে প্রতিবেদন করুন। "-1", নাল, খালি স্ট্রিং, কিছু এনাম, যাই হোক না কেন। কলকারীকে কেবল জানতে হবে যে কলটি ব্যর্থ হয়েছে, প্রায় কখনও ভয়াবহ বিবরণ নয়। এবং সেগুলি আপনার লগে থাকবে, তাই না? যে বিরল ক্ষেত্রে কলারের বিশদ প্রয়োজন তা নয়, এগিয়ে যান এবং বুদবুদ হয়ে যান, তবে স্বয়ংক্রিয়ভাবে অচিন্তিত ডিফল্ট হিসাবে নয়।

— UnconditionallyReinstateMonica
সূত্র

রিটার্ন মানগুলি দ্বারা ত্রুটিটি প্রতিবেদন করার সমস্যাটি হ'ল: ১. কলার যদি ব্যর্থতার বিষয়ে চিন্তা করে তবে তার বিশেষ মানটি পরীক্ষা করতে হবে। তবে অপেক্ষা করুন, এটি nullনাকি খালি স্ট্রিং? এটি -1 বা কোনও নেতিবাচক সংখ্যা? 2. যদি আহ্বানকারী গ্রাহ্য না করে (অর্থাত পরীক্ষা না) এই বিশালাকার মূল কারণ, যেমন একটি অসম্পর্কিত ত্রুটি অনুসরণ করার NullPointerException। বা আরও খারাপ: গণনাটি ভুল মান নিয়ে চলতে থাকে। ৩. যদি কলকারী যত্নশীল তবে প্রোগ্রামার এই পদ্ধতিটি ব্যর্থতার কথা মনে না করে, সংকলক তাকে মনে করিয়ে দেয় না। ব্যতিক্রমগুলির এই সমস্যাগুলি নেই, হয় আপনি ধরুন বা আপনি পুনর্নির্মাণ করুন।

— siegi

দুঃখিত, আমি এটি ডাউনভিট করতে হয়েছিল। আপনি যে পদ্ধতির বর্ণনা করেছেন (বিশেষ ফিরে আসার মানগুলির সাথে ব্যতিক্রমগুলি প্রতিস্থাপন করুন) ১৯ 1970০ এর দশকে, যখন সি ভাষার উদ্ভব হয়েছিল, এবং আধুনিক ভাষাগুলি ব্যতিক্রম হওয়ার অনেকগুলি ভাল কারণ রয়েছে এবং আমার কাছে প্রধানতমটি হ'ল ব্যতিক্রমগুলি সঠিকভাবে ব্যবহার করা জোরালো কোড লেখার পক্ষে আরও সহজ করে তোলে। এবং আপনার "বুদবুদ ব্যতিক্রমগুলি [...] অতিরিক্ত প্রচেষ্টা [...]" হ'ল স্পষ্টত ভুল: ব্যতিক্রম সম্পর্কে কিছুই করবেন না এবং তারা নিজেরাই এলোমেলো হয়ে উঠবে।

— রাল্ফ ক্লেবারহফ