সি # তে একটি এন্টারপ্রাইজ প্রকল্পের জন্য ত্রুটি কোড প্যাটার্ন তৈরির সেরা অভ্যাসসমূহ [বন্ধ]

Question

আমি একটি এন্টারপ্রাইজ প্রকল্পে কাজ করছি যা অনেক এসএমবি এবং উদ্যোগে স্থাপন করা হবে।
এই প্রকল্পের জন্য সমর্থন সংগ্রাম করা হবে এবং তাই আমি ত্রুটিগুলির জন্য কোডিং প্যাটার্ন তৈরি করতে চাই ( যেমন HTTP স্থিতি কোডগুলি )। এটি ডেস্কের লোকদের নথিগুলি উল্লেখ করতে এবং সমস্যাগুলি যত তাড়াতাড়ি সম্ভব সমস্যা সমাধানের জন্য সক্ষম করবে।

এটি করার জন্য সেরা অনুশীলন এবং প্রস্তাবনাগুলি কী কী?
এটি করার জন্য কোনও সহায়তা কার্যকর হবে।

Comments

এখানে অনেকগুলি সম্ভাব্য উত্তর রয়েছে বা ভাল উত্তরগুলি এই ফর্ম্যাটটির জন্য খুব দীর্ঘ। উত্তর সেটটি সংকীর্ণ করতে বা কয়েকটি অনুচ্ছেদে উত্তর দেওয়া যায় এমন একটি সমস্যা আলাদা করতে দয়া করে বিশদ যুক্ত করুন। এবং আপনি এখন পর্যন্ত কি চেষ্টা করেছেন?

— বেন ম্যাকডোগল

আপনার ব্যবসায় কীভাবে কাঠামোবদ্ধ তা নির্ভর করে। সি # তে আমরা সর্বদা ব্যবহারকারীকে আমাদের স্ট্যাকট্রেস মেইল ​​করার বা ত্রুটি বার্তার বিবরণ থেকে এটি অনুলিপি / আটকানোর সম্ভাবনা দিয়েছিলাম (আমাদের কোনও সুরক্ষার প্রয়োজনীয়তা ছিল না)।

— ফ্যালকন

Answer 1

ত্রুটি কোড এবং ত্রুটি রিটার্ন মানগুলির মধ্যে পার্থক্য রয়েছে। ব্যবহারকারী এবং সহায়তা ডেস্কের জন্য একটি ত্রুটি কোড। আপনার কোডটিতে কোনও ত্রুটির সম্মুখীন হয়েছে তা নির্দেশ করার জন্য একটি ত্রুটি রিটার্ন মান হ'ল একটি কোডিং কৌশল।

ত্রুটি রিটার্ন মানগুলি ব্যবহার করে কেউ ত্রুটি কোডগুলি প্রয়োগ করতে পারে তবে আমি তার বিরুদ্ধে পরামর্শ দেব। ব্যতিক্রমগুলি ত্রুটিগুলি প্রতিবেদন করার আধুনিক উপায় এবং তাদের মধ্যে ত্রুটি কোড বহন করার কোনও কারণ নেই।

এইভাবেই আমি এটিকে সংগঠিত করব (দ্রষ্টব্য যে 2-6 পয়েন্টগুলি ভাষা অজ্ঞাত্ত্বিক হয়):

1. অতিরিক্ত ErrorCodeসম্পত্তি সহ একটি কাস্টম ব্যতিক্রম প্রকার ব্যবহার করুন । মূল লুপের ক্যাচটি এই ক্ষেত্রটি স্বাভাবিকভাবে জানায় (লগ ফাইল / ত্রুটি পপ-আপ / ত্রুটির জবাব)। আপনার সমস্ত কোডে একই ব্যতিক্রম প্রকারটি ব্যবহার করুন।
2. 1 এ শুরু করবেন না এবং নেতৃস্থানীয় শূন্যগুলি ব্যবহার করবেন না। সমস্ত ত্রুটি কোডগুলি একই দৈর্ঘ্যে রাখুন, সুতরাং একটি ভুল ত্রুটি কোড চিহ্নিত করা সহজ। সাধারণত 1000 এ শুরু করা যথেষ্ট ভাল। তাদের ব্যবহারকারীর জন্য পরিষ্কারভাবে সনাক্তযোগ্য করে তুলতে নেতৃস্থানীয় 'ই' যুক্ত করুন (বিশেষত যখন সহায়তা ডেস্ক ব্যবহারকারীদের ত্রুটি কোডটি কীভাবে চিহ্নিত করতে হয় তা নির্দেশ করতে হবে) useful
3. সমস্ত ত্রুটি কোডের একটি তালিকা রাখুন, তবে আপনার কোডটিতে এটি করবেন না । বিকাশকারীদের জন্য উইকি-পৃষ্ঠায় একটি সংক্ষিপ্ত তালিকা রাখুন, যখন তাদের একটি নতুন কোডের প্রয়োজন হয় তখন তারা সহজেই সম্পাদনা করতে পারেন। সহায়তা ডেস্কের নিজস্ব উইকিতে একটি পৃথক তালিকা থাকা উচিত।
4. ত্রুটি কোডগুলিতে কোনও কাঠামো প্রয়োগ করার চেষ্টা করবেন না। সর্বদা হার্ড-টু-শ্রেণিবদ্ধ ত্রুটি থাকবে এবং আপনি ত্রুটিটি 45XX গ্রুপে বা 54xx গ্রুপে থাকা উচিত কিনা কয়েক ঘন্টা ধরে আলোচনা করতে চান না। ব্যবহারিক হতে হবে ।
5. আপনার কোডের প্রতিটি থ্রোকে একটি পৃথক কোড বরাদ্দ করুন। যদিও আপনি মনে করেন এটি একই কারণ, হেল্প ডেস্কের বিভিন্ন ক্ষেত্রে বিভিন্ন জিনিস করার প্রয়োজন হতে পারে। ব্যবহারকারীরা কী ভুল করেছেন তা স্বীকার করার চেয়ে তাদের উইকিতে "E1234: E1235" পাওয়া তাদের পক্ষে সহজ।
6. সহায়তা ডেস্ক যদি এটি জিজ্ঞাসা করে তবে ত্রুটি কোডগুলি বিভক্ত করুন। if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");আপনার কোডের একটি সাধারণ লাইন সাহায্য ডেস্কের জন্য আধ ঘন্টা বাঁচাতে পারে।

এবং কখনও ভুলে যাবেন না যে ত্রুটি কোডগুলির উদ্দেশ্য হ'ল সহায়তা ডেস্কের জন্য জীবনকে সহজ করে তোলা ।

Comments

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

— xdhmoore

আমি মনে করি পারস্পরিক সম্পর্ক আইডির মধ্যে সম্ভবত ত্রুটি কোড অন্তর্ভুক্ত করার কোনও উপায় রয়েছে যাতে এটি সহায়তা ডেস্কের জন্য মানব-পঠনযোগ্য ত্রুটি কোড হিসাবে এবং বিকাশকারীদের জন্য একটি ত্রুটি উদাহরণ আইডি হিসাবে পরিবেশন করতে পারে।

— xdmoore

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

— ম্যাথিয়াস বার্গার

Answer 2

আপনাকে প্রথমে সেই অঞ্চলগুলি বিচ্ছিন্ন করতে হবে যেখানে ত্রুটি দেখা দিতে পারে এবং ব্যবহারকারী-দৃশ্যমান। তারপরে আপনি এগুলি নথিভুক্ত করতে পারেন। এটি যে সহজ।

ঠিক আছে, তাত্ত্বিকভাবে সরল .. বাস্তবে ত্রুটিগুলি জঘন্য জায়গায় সমস্ত ঘটতে পারে, এবং তাদের প্রতিবেদন করা দুর্দান্ত কোডটিকে লগিং, ব্যতিক্রম নিক্ষেপ এবং পরিচালনা এবং একটি ফেরতের মানগুলি পাস করে mons

আমি তখন 2-পদক্ষেপের পদ্ধতির প্রস্তাব করব। প্রথমটি হ'ল লগ করা, প্রচুর লগ এবং লগ করা।

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

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

Answer 3

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

Comments

আমি এই ব্যক্তির প্রশংসা করব যিনি এই উত্তরটি 1 থেকে 0 থেকে

— কমিয়ে

আমাকে ডাউনভোটিং ছিল না (এটি গুরুত্বপূর্ণ যে এটি নয়, এটি পেরে উঠুন), তবে আমি মনে করি ভাষার ক্ষেত্রেও প্রত্যাবর্তনের মূল্যবোধের জন্য বিদ্যমান সমর্থন রয়েছে।

— gbjbaanb

এটা আমার কাছে গুরুত্বপূর্ণ; যদি আমি ভুল, আমি জানতে চাই যাতে আমি শিখতে পারি :-p আপনি কীভাবে বোঝাতে চান, রিটার্ন মানগুলির জন্য বিদ্যমান সমর্থন? একটি ত্রুটি কোড থেকে একটি সাধারণ রিটার্ন মান পৃথক করতে আপনাকে নদীর গভীরতানির্ণয় লিখতে হবে না? একটি সিস্টেমের সীমানায় একটি ত্রুটি কোডে একটি ব্যতিক্রম অনুবাদ করা একটি জিনিস, তবে আপনার সিস্টেমে এগুলি জাগ্রুল করা এমন একটি বিষয় যা সাধারণত পরামর্শ দেওয়া হয় না। আমি বিশ্বাস করি যে প্র্যাকমেটিক প্রোগ্রামার এই ধরণের জিনিসগুলির উল্লেখ করেছে।

— স্টেফান বিলিয়েট

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

— gbjbaanb

আমি আপনাকে ভোট দিলাম না (এটিকে সহজ করে নিন, অন্যথায় প্রত্যেককেই এটির পুনরাবৃত্তি করতে হবে :)। আপনি যদি সার্ভিস ডেস্কে কাজ করে বা ফোন করেছিলেন, তবে একটি ত্রুটির বার্তার চেয়ে স্বল্প সংখ্যায় যোগাযোগ করা অনেক সহজ। মৌখিকভাবে জানানো হলে একটি ত্রুটি বার্তা পরিবর্তন করার গ্যারান্টিযুক্ত।

— কোডিম 15