এই বার্তাগুলি অন্যান্য বিকাশকারীদের জন্য
অ্যাপ্লিকেশন ডিবাগ করতে তাদের সহায়তা করতে এই বার্তাগুলি বিকাশকারীদের দ্বারা পড়ার আশা করা হচ্ছে । এটি দুটি ফর্ম নিতে পারে:
সক্রিয় ডিবাগিং। কোড লিখতে গিয়ে কী ঘটেছিল তা বের করার চেষ্টা করার সময় আপনি আসলে একটি ডিবাগার চালাচ্ছেন। এই প্রসঙ্গে, একটি সহায়ক ব্যতিক্রম আপনাকে কী ভুল হচ্ছে তা বুঝতে সহজতর করে বা শেষ পর্যন্ত একটি কাজের প্রস্তাব দেওয়ার পরামর্শ দিয়ে সহায়তা করবে (যদিও এটি alচ্ছিক)।
প্যাসিভ ডিবাগিং। কোড উত্পাদন চালায় এবং ব্যর্থ হয়। ব্যতিক্রম লগড হয়েছে, তবে আপনি কেবল বার্তাটি এবং স্ট্যাক ট্রেস পাবেন। এই প্রসঙ্গে, একটি সহায়ক ব্যতিক্রম বার্তা আপনাকে দ্রুত বাগ স্থানীয়করণে সহায়তা করবে।
যেহেতু এই বার্তাগুলি প্রায়শই লগ থাকে তাই এর অর্থ হ'ল আপনার সেখানে সংবেদনশীল তথ্য অন্তর্ভুক্ত করা উচিত নয় (যেমন ব্যক্তিগত কী বা পাসওয়ার্ডগুলি এমনকি অ্যাপটি ডিবাগ করার জন্য দরকারী হতে পারে)।
উদাহরণস্বরূপ, IOSecurityExceptionকোনও ফাইল লেখার সময় নিক্ষিপ্ত একটি ব্যতিক্রম সমস্যা সম্পর্কে খুব স্পষ্ট নয়: এটি কি কারণ আমাদের কোনও ফাইল অ্যাক্সেস করার অনুমতি নেই? অথবা আমরা এটি পড়তে পারি, তবে লিখব না? অথবা সম্ভবত ফাইলটি বিদ্যমান নেই এবং আমাদের সেখানে ফাইল তৈরি করার অনুমতি নেই? অথবা সম্ভবত এটি লক হয়ে গেছে (আশা করা যায়, ব্যতিক্রমের ধরণটি এক্ষেত্রে পৃথক হবে তবে বাস্তবে, প্রকারগুলি কখনও কখনও গুপ্ত হতে পারে)। অথবা হতে পারে কোড অ্যাক্সেস সুরক্ষা আমাদের কোনও আই / ও অপারেশন করতে বাধা দেয়?
পরিবর্তে:
আইওএসিকিউরিটি এক্সেপশন: ফাইলটি পাওয়া গেছে তবে এর সামগ্রীগুলি পড়ার অনুমতি অস্বীকার করা হয়েছিল।
আরও অনেক স্পষ্ট। এখানে, আমরা তাত্ক্ষণিকভাবে জানি যে ডিরেক্টরিতে অনুমতিগুলি সঠিকভাবে সেট করা আছে (অন্যথায়, আমরা ফাইলটি বিদ্যমান তা জানতে সক্ষম হব না) তবে ফাইল স্তরের অনুমতিগুলি সমস্যাযুক্ত।
এর অর্থ হ'ল আপনি যদি অতিরিক্ত কোনও তথ্য সরবরাহ করতে না পারেন যা ইতিমধ্যে ব্যতিক্রমের ধরণীতে নেই তবে আপনি বার্তাটি খালি রাখতে পারেন। DivisionByZeroExceptionবার্তাটি অতিরিক্ত। অন্যদিকে, বেশিরভাগ ভাষাগুলি আপনাকে তার বার্তা উল্লেখ না করেই একটি ব্যতিক্রম ছুঁড়তে দেয় ভিন্ন কারণে এটি করা হয়: হয় না ডিফল্ট বার্তাটি ইতিমধ্যে উপলব্ধ, অথবা প্রয়োজনে এটি পরে তৈরি করা হবে (এবং এটির উত্পন্নকরণ) বার্তাটি ব্যতিক্রম প্রকারের মধ্যে আবদ্ধ থাকে, যা সঠিকভাবে বোঝায়, "OOPly" স্পিকিং)।
নোট করুন যে প্রযুক্তিগত (প্রায়শই পারফরম্যান্স) কারণে, কিছু বার্তাগুলি তাদের হওয়া উচিতের চেয়ে অনেক বেশি ক্রিপ্টিক হয়। । নেট এর NullReferenceException:
অবজেক্টের রেফারেন্স কোনও অবজেক্টের উদাহরণে সেট করা হয়নি।
এটি কোনও বার্তার একটি দুর্দান্ত উদাহরণ যা সহায়ক নয়। সহায়ক বার্তাটি হ'ল:
productযখন ডাকা হবে তখন অবজেক্টের রেফারেন্স কোনও অবজেক্টের উদাহরণে সেট করা নেই product.Price।
এই বার্তা শেষ ব্যবহারকারীদের জন্য নয়!
শেষ ব্যবহারকারীদের ব্যতিক্রম বার্তা দেখার আশা করা হয় না। কখনও। যদিও কিছু বিকাশকারী এই বার্তাগুলি ব্যবহারকারীদের দেখিয়ে শেষ করেছেন, এটি ব্যবহারকারীর দুর্বল অভিজ্ঞতা এবং হতাশার দিকে পরিচালিত করে। বার্তা যেমন:
অবজেক্টের রেফারেন্স কোনও অবজেক্টের উদাহরণে সেট করা হয়নি।
শেষ ব্যবহারকারীর কাছে একেবারে কিছুই নয়, এবং এটি সর্বদাই এড়ানো উচিত।
সবচেয়ে খারাপ পরিস্থিতি হ'ল একটি বিশ্বব্যাপী চেষ্টা / ধরা যা ব্যবহারকারীর ব্যতিক্রম ছোঁড়ে এবং অ্যাপটি থেকে বেরিয়ে আসে। এমন একটি অ্যাপ্লিকেশন যা এর ব্যবহারকারীদের সম্পর্কে চিন্তা করে:
প্রথম স্থানে ব্যতিক্রমগুলি পরিচালনা করে। বেশিরভাগগুলি ব্যবহারকারীকে বিরক্ত না করে পরিচালনা করা যায়। নেটওয়ার্ক ডাউন? কয়েক সেকেন্ড অপেক্ষা করে আবার চেষ্টা করবেন না কেন?
কোনও ব্যবহারকারীকে ব্যতিক্রমী ক্ষেত্রে অ্যাপ্লিকেশন পরিচালনা করতে বাধা দেয়। আপনি যদি ব্যবহারকারীকে দুটি সংখ্যা লিখতে এবং প্রথমটিকে দ্বিতীয়টির সাথে ভাগ করতে বলেন তবে আপনি কয়েক সেকেন্ড পরে তাকে দোষারোপ করার জন্য কেন ব্যবহারকারীকে দ্বিতীয় ক্ষেত্রে শূন্য প্রবেশ করতে দিবেন? লাল রঙের পাঠ্য বাক্সটি হাইলাইট করার বিষয়ে (একটি সহায়ক সরঞ্জাম টিপ দিয়ে যে নম্বরটি শূন্যের চেয়ে আলাদা হওয়া উচিত) এবং ক্ষেত্রটি লাল না হওয়া পর্যন্ত বৈধতা বোতামটি অক্ষম করার বিষয়ে কী?
কোনও ব্যবহারকারীকে কোনও ফর্মে কোনও ক্রিয়া সম্পাদনের জন্য আমন্ত্রণ জানিয়েছে যা কোনও ত্রুটি নয়। কোনও ফাইল অ্যাক্সেস করার জন্য পর্যাপ্ত অনুমতি নেই? ব্যবহারকারীকে প্রশাসনিক অনুমতি দেওয়ার জন্য বা অন্য কোনও ফাইল বাছাই করতে বলবেন না কেন?
যদি অন্য কোনও কাজ না করে তবে একটি সহায়ক, বন্ধুত্বপূর্ণ ত্রুটি দেখায় যা ব্যবহারকারীর হতাশা হ্রাস করতে বিশেষভাবে লেখা হয়েছে, ব্যবহারকারীকে কী ভুল হয়েছে তা বুঝতে সাহায্য করুন এবং শেষ পর্যন্ত সমস্যাটি সমাধান করতে সহায়তা করুন এবং ভবিষ্যতে ত্রুটি রোধে সহায়তা করুন (যখন প্রযোজ্য হবে)।
আপনার প্রশ্নে, আপনি ব্যতিক্রম হিসাবে দুটি বার্তা রাখার পরামর্শ দিয়েছেন: বিকাশকারীদের জন্য একটি প্রযুক্তিগত ঠিকানা এবং শেষ ব্যবহারকারীদের জন্য একটি। যদিও এটি কিছু ছোটখাটো ক্ষেত্রে বৈধ পরামর্শ, বেশিরভাগ ব্যতিক্রম এমন স্তরে উত্পাদিত হয় যেখানে ব্যবহারকারীদের জন্য অর্থবোধক বার্তা তৈরি করা অসম্ভব। ধরুন DivisionByZeroExceptionএবং কল্পনা করুন যে আমরা ব্যতিক্রমটি ঘটতে বাধা দিতে পারি না এবং এটি নিজেই পরিচালনা করতে পারি না। বিভাগটি যখন ঘটে তখন ফ্রেমওয়ার্কটি (যেহেতু এটি কাঠামোটি, এবং ব্যবসায়ের কোড নয়, যা ব্যতিক্রম ছুঁড়ে) কোনও ব্যবহারকারীের জন্য সহায়ক বার্তাটি কী হবে তা কি জানেন? একেবারে না:
শূন্য দ্বারা বিভাজন ঘটেছে। [ঠিক আছে]
পরিবর্তে, কেউ এটিকে ব্যতিক্রম ছুঁড়ে দিতে দেয় এবং তারপরে এটি এমন একটি উচ্চ স্তরে ধরে ফেলতে পারে যেখানে আমরা ব্যবসায়ের প্রসঙ্গটি জানতাম এবং শেষ ব্যবহারকারীকে প্রকৃতপক্ষে সহায়তা করার জন্য সেই অনুসারে কাজ করতে পারি, এভাবে কিছু দেখাচ্ছে:
E13 ক্ষেত্রের ক্ষেত্রে ডি 13 এর ক্ষেত্রের মানটির সমান হতে পারে না, কারণ এই মানগুলির বিয়োগটি বিভাজন হিসাবে ব্যবহৃত হয়। [ঠিক আছে]
অথবা হতে পারে:
এটিপি পরিষেবাদির দ্বারা প্রতিবেদন করা মানগুলি স্থানীয় ডেটাগুলির সাথে সঙ্গতিপূর্ণ নয়। স্থানীয় ডেটা সিঙ্কের বাইরে চলে যাওয়ার কারণে এটি হতে পারে। আপনি কি শিপিংয়ের তথ্য সিঙ্ক্রোনাইজ করতে এবং আবার চেষ্টা করতে চান? [হ্যাঁ না]
এই বার্তাগুলি বিশ্লেষণের জন্য নয়
ব্যতিক্রম বার্তাগুলি পার্স করা বা প্রোগ্রামগতভাবে ব্যবহার করা হবে বলে আশা করা যায় না। যদি আপনি মনে করেন যে অতিরিক্ত তথ্য কলকারীর দ্বারা প্রয়োজন হতে পারে তবে বার্তাটির পাশাপাশি এটি ব্যতীত অন্তর্ভুক্ত করুন। এটি গুরুত্বপূর্ণ, কারণ বার্তাটি কোনও বিজ্ঞপ্তি ছাড়াই পরিবর্তিত হতে পারে। প্রকারটি ইন্টারফেসের একটি অংশ, তবে বার্তাটি নয়: ব্যতিক্রম হ্যান্ডলিংয়ের জন্য কখনই এর উপর নির্ভর করবেন না।
ব্যতিক্রম বার্তাটি কল্পনা করুন:
ক্যাশিংয়ের সাথে সংযোগ স্থাপনের সময় 500 এমএস অপেক্ষা করার পরে সময় শেষ হয়ে যায়। হয় সময়সীমা বাড়াতে বা সার্ভারের কার্যকারিতা হ্রাস করতে পারফরম্যান্স পর্যবেক্ষণটি পরীক্ষা করে দেখুন। ক্যাচিং সার্ভারের জন্য অপেক্ষা করার গড় সময় ছিল 6 এমএস। গত মাসের জন্য, 4 এমএস গত সপ্তাহে এবং 377 এমএসের জন্য। শেষ ঘন্টা জন্য।
আপনি "500", "6", "4" এবং "377" মান বের করতে চান। পার্সিংয়ের জন্য আপনি যে পদ্ধতির ব্যবহার করবেন সে সম্পর্কে কিছুটা চিন্তা করুন এবং কেবল তখনই পড়া চালিয়ে যান।
আপনার ধারণা আছে? গ্রেট।
এখন, মূল বিকাশকারী একটি টাইপো আবিষ্কার করেছেন:
Connecting to the caching sever timed out after waiting [...]
হতে হবে:
↓
Connecting to the caching server timed out after waiting [...]
তদুপরি, বিকাশকারী বিবেচনা করে যে মাস / সপ্তাহ / এক ঘন্টা বিশেষভাবে প্রাসঙ্গিক নয়, তাই তিনি একটি অতিরিক্ত পরিবর্তনও করেন:
ক্যাচিং সার্ভারের জন্য অপেক্ষা করার গড় সময় ছিল 6 এমএস। গত মাসে, 5 এমএস গত 24 ঘন্টা এবং 377 এমএসের জন্য। শেষ ঘন্টা জন্য।
আপনার পার্সিং দিয়ে কি হয়?
পার্সিংয়ের পরিবর্তে, আপনি ব্যতিক্রমী বৈশিষ্ট্যগুলি ব্যবহার করতে পারেন (যার মধ্যে ডেটা সিরিয়ালাইজ করার সাথে সাথে এটি যা খুশি থাকতে পারে):
{
message: "Connecting to the caching [...]",
properties: {
"timeout": 500,
"statistics": [
{ "timespan": 1, "unit": "month", "average-timeout": 6 },
{ "timespan": 7, "unit": "day", "average-timeout": 4 },
{ "timespan": 1, "unit": "hour", "average-timeout": 377 },
]
}
}
এখন এই ডেটা ব্যবহার করা কত সহজ?
কখনও কখনও (যেমন। নেট মধ্যে) বার্তাটি এমনকি ব্যবহারকারীর ভাষায় অনুবাদ করা যেতে পারে (আইএমএইচও, সেই বার্তাগুলি অনুবাদ করা একেবারেই ভুল, যেহেতু কোনও বিকাশকারীই ইংরেজিতে পড়তে পারবেন বলে আশা করা যায়)। এই জাতীয় বার্তাগুলি পার্স করা অসম্ভবের কাছাকাছি।