আমি কেন চেষ্টা-ক্যাচের মধ্যে সমস্ত বিবৃতি লিখব?

Question

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

Comments

এটি একই লোকের মত বাজ শর্তগুলির মতো শোনাচ্ছে যা বলে যে আরও ভাল পারফরম্যান্সের জন্য সমস্ত এসকিউএল স্টোর করা পদ্ধতি হিসাবে লেখা উচিত।

— এডমিশন

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

— জেফো

@ জেফ ও - আমি আসলে বিশ্বাস করি যে সফটওয়্যার বিকাশে প্রতিপক্ষ একটি মালবাহী ট্রেন।

— জোরিস টিমারম্যানস

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

— ব্রুক 13

অনুরোধের বিষয়টি অপ্রাসঙ্গিক ... কেবল "আমার সংস্থার প্রধান বলেছেন আমাকে কোড করা উচিত ..." বলা একটি বড় লাল পতাকা। এটা মাইক্রো ম্যানেজমেন্ট ... এটি তার কাজ নয়।

— জোয়েলফ্যান

Answer 1

আমার সংস্থার প্রধান বলেছেন যে আমাকে অবশ্যই সমস্ত লিখতে হবে, অর্থাত্ চেষ্টা কোডের বিবৃতিতে আমার সমস্ত কোড।

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

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

ব্যতিক্রম হ্যান্ডলিং সত্যিই খুব সহজ:

ব্যতিক্রম ধরুন

• যখনই আপনার ব্যতিক্রমের প্রতিক্রিয়া হিসাবে একটি বিশেষ ক্রিয়া দরকার
• যখনই কোনও ব্যতিক্রমহীনতা অবলম্বন করে প্রোগ্রামটি বেমানান অবস্থায় ছেড়ে দেয়

আপনি যদি এটির বিষয়ে চিন্তা করেন তবে সর্বাধিক সবসময় কেবলমাত্র একটি জায়গা রয়েছে যা আসন্ন ব্যতিক্রমগুলি পরিচালনা করতে ভাল। এবং এইভাবে হ্যান্ডলারটি সেই জায়গায় হওয়া উচিত।

অনেক ব্যতিক্রম এমনকি প্রথম স্থানে ফেলে দেওয়া উচিত নয়, সুতরাং ব্যতিক্রম পরিচালনার চারপাশে আপনার নিয়ন্ত্রণ কাঠামো তৈরি করবেন না, বরং যখনই এবং যেখানেই সম্ভব ব্যতিক্রমের সম্ভাব্য ঘটনা এড়ানোর চেষ্টা করুন।

যখন জিনিসগুলি (অপ্রত্যাশিতভাবে) ভুল হয়ে যায় তখন তাড়াতাড়ি ক্রাশ করতে ভুলবেন না। সমস্ত কোড ট্রাই-ক্যাচ স্টেটমেন্টে রাখা অযৌক্তিক, তবে সমস্ত ব্যতিক্রমগুলি রিপোর্ট এবং লগ করতে ভুলবেন না।

Comments

+1 কেবল এটিকে শোরগোলের কোডে নিয়ে যায় না, বরং আরও খারাপ পারফরম্যান্সও দেয়। আপনি যখন কোনও চেষ্টা ব্লকে স্টেটমেন্টগুলি রাখেন, হটস্পট সংকলক অন্যথায় সেগুলি করতে পারে এমন অপটিমাইজেশন প্রয়োগ করতে সক্ষম হবে না।

— অলিভার ওয়েইল

@ অলিভার ওয়েইলর: হটস্পট সংকলক চেষ্টা / ধরার ব্লকগুলিতে কোন অপ্টিমাইজেশন করে না তা ব্যাখ্যা করে আপনার কাছে একটি উদ্ধৃতি রয়েছে?

— কায়প্রো দ্বিতীয়

Answer 2

তবে কী লেবেলগুলি তৈরি হওয়ার পরে, ফর্মের অবস্থান নির্ধারণ করা হবে সেখানে ব্যতিক্রম হবে তা ভাবতে খুব মুরগি নয়। এমন সাধারণ অপারেশনগুলিতে ব্যতিক্রম রয়েছে এমন উদাহরণ রয়েছে।

অবশ্যই হ্যাঁ! জিনিসগুলির ভুল হওয়ার জন্য সর্বদা একটি উপায় রয়েছে যা আপনি আগেই ভাবেননি। এবং "মুরগী-হৃদয়" এই প্রসঙ্গে ব্যবহার করার জন্য একটি হাস্যকর অভিব্যক্তি; সফ্টওয়্যার বিকাশ সম্ভাব্য সমস্যা উপেক্ষা করে আপনার মেশিমো প্রমাণ করার বিষয়ে নয়।

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

Comments

আমার অ্যাপ্লিকেশনগুলি ব্যতিক্রম ছোঁড়ার চেয়ে ভাল জানেন বা তারা তাদের জীবনের মারধর করবে। একবার তারা যদি মনে করে যে আপনি মুরগী-মনের, তারা আপনার সমস্ত ক্রাশ হয়ে যাবে।

— জেফো

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

— ফ্যালকন

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

— মাইকেল বর্গওয়ার্ট

@ মিশেল বোরওয়ার্ট: সম্ভবত আমি ভুল হয়েছি। সেক্ষেত্রে আমি ক্ষমা চাইছি। এটি হতে পারে যে আপনার নিজের প্রশ্নে কেবল ডাউনটোটই আমাকে এই ধারণা করতে বাধ্য করেছিল যে আপনি এখানে ডাউনভিট করেছেন। দুঃখিত।

— ফ্যালকন

Answer 3

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

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

Comments

+1: আপনি অবিলম্বে এটির সাথে সঠিকভাবে ডিল করতে না পারলে কখনই ব্যতিক্রম ধরবেন না। (হায়, মাঝেমধ্যে আপনাকে এটিকে ফাঁসানোর জন্য ফাঁদে ফেলতে হবে তবে এপিআই কর্সার অংশ হিসাবে এটি অন্য ধরণের হিসাবে ট্যাগ করা হয়েছে: আমি এটি ঘৃণা করি))

— ডোনাল ফেলো

Answer 4

সামগ্রিকভাবে, চেষ্টা / ক্যাচ ব্যবহার করে যা অনেকটা হ্রাস করা হয়, কারণ ক্যাচ ব্লক সংস্থানগুলির দিক থেকে এত ব্যয়বহুল। ব্যবহার / ধরার ব্যবহার আমাকে ঝুঁকি ব্যবস্থাপনার কথা মনে করিয়ে দেয় । ঝুঁকি ব্যবস্থাপনার দুটি মাত্রা রয়েছে:

1. ঝুঁকি হওয়ার সম্ভাবনা
2. এতে ক্ষতি হতে পারে

এখন, আপনি যদি আপনার বাড়ির বাইরে চলে যান তবে পিয়ানো আপনার মাথায় কোথাও পড়ছে এমনটি হওয়ার সম্ভাবনা খুব কম (সম্ভবত 0.001%), তবে আপনাকে হত্যা করতে পারে।

ব্যতিক্রম হ্যান্ডলিং এর মত হয়। ব্লক চেষ্টা করুন ব্যয়বহুল নয়। তবে ক্যাচ ব্লকটি সত্যই ব্যয়বহুল, কারণ এটি স্ট্যাক ট্রেসের একটি টেবিল তৈরি করতে এবং অন্যান্য জিনিসগুলি করা দরকার। অতএব ট্র্যাচ / ক্যাচ ব্লক সম্পর্কে সিদ্ধান্ত নেওয়ার ক্ষেত্রে, আপনি সম্ভবত কতবার ক্যাচ ব্লকে আঘাত করেছেন তা বিবেচনা করা উচিত। 10,000 টি ব্যবহারের মধ্যে যদি আপনি কেবল 1 বার আঘাত করেন তবে এটি ব্যবহার করুন। তবে যদি এটি কোনও ফর্ম হয় এবং ব্যবহারকারী সম্ভবত এটি 50% বার সঠিকভাবে পূরণ না করে তবে আপনার সেখানে চেষ্টা করার চেষ্টা / ক্যাপ ব্লকটি এড়ানো উচিত।

যে জায়গাগুলিতে ব্যতিক্রম হওয়ার সম্ভাবনা বেশি, সেখানে if {} else {}ব্যতিক্রম ঘটনা এড়াতে ব্লক ব্যবহার করার পরামর্শ দেওয়া হয়। উদাহরণস্বরূপ, আপনি লেখার পরিবর্তে যেখানে দুটি সংখ্যা ভাগ করতে চান:

try
{
    int result = a/b;
}
catch (DivisionByZeroException ex)
{
    // Showing a message here, and logging of course.
}

আপনার লেখা উচিত:

if (b == 0)
{
    int result = a/b;
}
else
{
    // Showing a message to user to change the value of b, etc.
}

Comments

মূলত কেবল অ্যাপ্লিকেশন যুক্তিযুক্ত "ব্যতিক্রমগুলি" মোকাবেলা করার জন্য / অন্যটি ব্যবহার করার জন্য +1।

— মরগান হেরলকার 13

যদি এটি ব্যবহারকারী-সম্পর্কিত হয় তবে মনে রাখবেন যে কম্পিউটারগুলি মানুষের চেয়ে ব্যাপকভাবে দ্রুত। ৫০% ফর্ম জমা দেওয়ার ক্ষেত্রে ব্যতিক্রম কেবলমাত্র অনেক ব্যবহারকারীর সাথেই কয়েক সেকেন্ডের কয়েক সেকেন্ডে সম্ভবত ঘটে।

— ডোনাল ফেলো

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

— কায়প্রো দ্বিতীয়

@ cosmic.osmo, আপনি কি স্ট্যাকট্রেসটি পুনরুদ্ধার করেন বা কেবল এটি ধরেন?

Answer 5

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

Comments

লগিং জন্য +1। বুনো প্রোগ্রামগুলি কালো বক্স হয়। যখন তারা ব্যর্থ হয়, "এখানে যা ঘটেছিল" বলে একটি লগ সমস্যা সমাধানে খুব দীর্ঘ পথ অতিক্রম করে। আমার প্রোগ্রামগুলিতে আমার ত্রুটি ছিল যা অপ্রতীকৃত হয়ে গেছে এবং লগটিতে আমি তাদের খুঁজে পাওয়ার পরে সেগুলি অনাবৃত হয়েছিল।

— অ্যান্ড্রু নীলি 14

Answer 6

আমি ব্যক্তিগতভাবে ব্যাতিক্রম করতে পারি না, এগুলি হ'ল অত্যন্ত, খুব, সঠিকভাবে পরিচালনা করা খুব কঠিন। এবং দুর্নীতিগ্রস্ত ডেটা উদঘাটন করার চেষ্টা করা হ'ল খুব, খুব, খুব শক্ত!

http://blogs.msdn.com/b/mgrier/archive/2004/02/18/75324.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

http://www.joelonsoftware.com/items/2003/10/13.html

আপনি যদি প্রতিটি ফাংশনকে কল না করেন তবে:

try
{
    TrivialFunction();
}
catch(TypeAException)
{
    //MaybeFix
}
catch(TypeBException)
{
    //MaybeFix
}
catch(TypeCException)
{
    //NO FIX - CORRUPT DATA
}
catch(TypeDException)
{
    //NO FIX - UNKNOWN STATE
}
catch(OutOfMemoryException)
{
    //Try to fix this one! Destructors might allocate on their own ;)
}
catch(Exception)
{
    //Nothing to see here, move on, everything is OK ;)
}

আপনি প্রতিটি প্রস্থান পয়েন্টে সঠিকভাবে পরিষ্কার করবেন এমন কোনও উপায় নেই। ব্যতিক্রমগুলি হার্ড!

ব্যতিক্রম সম্পর্কে একমাত্র ভাল বিষয় হ'ল আপনি যদি এগুলি না পান তবে অ্যাপ্লিকেশনটি অপ্রত্যাশিত আচরণের উপর ক্র্যাশ হয়ে যায়।