প্রথম বনাম ব্যতিক্রম হ্যান্ডলিং পরীক্ষা করুন?

Question

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

পাইথন কোডের একটি নমুনা এখানে:

# Checking First
for eachLine in open("../../data/sketch.txt"):
    if eachLine.find(":") != -1:
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())

# Exception handling        
for eachLine in open("../../data/sketch.txt"):
    try:
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())
    except:
        pass

প্রথম উদাহরণটি সরাসরি ফাংশনটিতে সমস্যা নিয়ে .splitকাজ করে। দ্বিতীয়টি কেবল ব্যতিক্রম হ্যান্ডলারটি এটির মোকাবেলা করতে দেয় (এবং সমস্যাটিকে উপেক্ষা করে)।

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

দু'জনের মধ্যে কোনটিকে সাধারণত উত্তম অনুশীলন হিসাবে বিবেচনা করা হয়?

Comments

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

— জেসন সেবারিং

শুধু "ফাইল বিদ্যমান চেক" ফাঁদে পড়বেন না। ফাইলটি আছে = ফাইলের অ্যাক্সেস আছে, অথবা এটি 10 MS এটা আমার ফাইল খোলা কল, ইত্যাদি পেতে লাগে মধ্যে উপস্থিত হবে! Blogs.msdn.com/b/jaredpar/archive/2009/04/27/...

— বিলি ওনিল

ব্যতিক্রমগুলি পাইথনে অন্য ভাষার চেয়ে আলাদাভাবে ভাবা হয়। উদাহরণস্বরূপ কোনও সংগ্রহের মাধ্যমে পুনরাবৃত্তি করার উপায়টি যদি কোনও ব্যতিক্রম ছুঁড়ে না দেয় ততক্ষণে এটিতে .next () কল করা।

— WuHoUnited 14

@ এমেরাল্ডকোড.কম এটি পাইথন সম্পর্কে সম্পূর্ণ সত্য নয়। আমি নির্দিষ্টকরণগুলি জানি না, তবে ভাষাটি সেই দৃষ্টান্তের চারপাশে তৈরি করা হয়েছে, সুতরাং ব্যতিক্রম ছোঁড়া অন্যান্য ভাষার মতো প্রায় ব্যয়বহুল নয়।

— ইজকাটা

এটি বলেছিল, উদাহরণস্বরূপ, আমি গার্ড স্টেটমেন্টটি ব্যবহার করব if -1 == eachLine.find(":"): continue:, তবে লুপের বাকী অংশগুলিও ইন্টেন্ট করা হবে না।

— ইজকাটা

Answer 1

.NET- এ, ব্যতিক্রমগুলির অতিরিক্ত ব্যবহার এড়াতে সাধারণ অনুশীলন। একটি যুক্তি পারফরম্যান্স:। নেট, একটি ব্যতিক্রম নিক্ষেপ করা গণনামূলকভাবে ব্যয়বহুল।

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

আর্গুমেন্টের কেন্দ্রস্থলে নিম্নলিখিত উদ্ধৃতিটি রয়েছে:

যুক্তিটি হ'ল আমি ব্যতিক্রমগুলি "গোটো" এর চেয়ে ভাল বলে বিবেচনা করি, যা ১৯60০ এর দশক থেকে ক্ষতিকারক হিসাবে বিবেচিত হয়, এতে তারা কোডের একটি বিন্দু থেকে অন্য বিন্দুতে আকস্মিক লাফ তৈরি করে। আসলে তারা গোটোর চেয়ে উল্লেখযোগ্যভাবে খারাপ:

1. তারা উত্স কোড অদৃশ্য । কোডগুলির একটি ব্লকের দিকে লক্ষ্য রেখে, ফাংশনগুলি যা ব্যতিক্রমগুলি ছুঁড়ে ফেলতে পারে বা না পারে, কোন ব্যতিক্রম ছুঁড়ে দেওয়া হবে এবং কোথা থেকে এটি দেখার কোনও উপায় নেই। এর অর্থ হ'ল এমনকি সতর্ক কোড পরিদর্শনও সম্ভাব্য বাগগুলি প্রকাশ করে না।

২. তারা কোনও ফাংশনের জন্য অনেকগুলি সম্ভাব্য প্রস্থান পয়েন্ট তৈরি করে। সঠিক কোডটি লিখতে, আপনাকে অবশ্যই আপনার ক্রিয়াকলাপের মাধ্যমে প্রতিটি সম্ভাব্য কোড পাথ সম্পর্কে ভাবতে হবে। প্রতিবার যখন আপনি কোনও ফাংশন কল করেন যা ব্যতিক্রম বাড়াতে পারে এবং স্পটটিতে এটি ধরা না দেয়, আপনি হঠাৎ করে বন্ধ হয়ে যাওয়া ফাংশনগুলির দ্বারা সৃষ্ট বিস্মিত বাগের সুযোগ তৈরি করেন, কোনও অসঙ্গতিপূর্ণ অবস্থায় ডেটা রেখে যান বা অন্য কোড পাথ যা আপনি করেননি ভাবো.

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

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

সবসময় ঘটে যাওয়া জিনিসগুলির জন্য আপনার ব্যতিক্রম ছোঁড়া উচিত নয়। তারপরে তারা "অর্ডিনারি" হতেন।

Comments

এখানে অন্য একটি বিষয়: ব্যতিক্রম লগিং যদি অ্যাপ্লিকেশন-ব্যাপী সক্ষম হয়, কেবলমাত্র ব্যতিক্রমী অবস্থার জন্য ব্যতিক্রম ব্যবহার করা ভাল, অধ্যক্ষগুলির জন্য নয়। অন্যথায় লগ বিশৃঙ্খল হয়ে যাবে এবং আসল ত্রুটি সৃষ্টিকারী কারণগুলি অস্পষ্ট করা হবে।

— রওয়ং

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

— mattnz

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

— জোমরনো

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

— মার্ক বুথ

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

— jmoreno

Answer 2

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

তবে বিবৃতি ব্যতীত খালি except:বক্তব্যের পাশাপাশি বিদেশেও সাবধান থাকবেন , যেহেতু তারা উভয়ই বাগটি মাস্ক করতে পারে - এরকম কিছু আরও ভাল হবে:

for eachLine in open("../../data/sketch.txt"):
    try:
        role, lineSpoken = eachLine.split(":",1)
    except ValueError:
        pass
    else:
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())

Comments

একটি নেট প্রোগ্রামার হিসাবে, আমি এটাকে ক্রিঞ্জ করি। তবে তারপরেও, আপনি লোকেরা সবকিছু অদ্ভুত করেন। :)

— ফিল

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

— জ্যাক

সুতরাং আপনি অপ্রত্যাশিত ত্রুটি এবং প্রত্যাশিত ধরণের প্রত্যাবর্তনের মানগুলির জন্য একই প্রক্রিয়াটি ব্যবহার করে শেষ করেন। এটি একটি সংখ্যার হিসাবে 0 ব্যবহার করার মতো দুর্দান্ত, এবং একটি অবৈধ পয়েন্টার যা আপনার প্রসেসটি 128 + সিগসাইজিভির একটি প্রস্থান কোড দিয়ে প্রস্থান করবে, কারণ কতটা সুবিধাজনক, আপনার এখন বিভিন্ন জিনিসের প্রয়োজন নেই। স্ফুলির মতো! বা পায়ের আঙ্গুলের সাথে জুতা ...

— ইয়োম্যান

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

— lvc

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

— ইয়োম্যান

Answer 3

একটি ব্যবহারিক পদ্ধতির

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

1. ধরে নিন যে সমস্ত ব্যবহারকারীর ইনপুটটি খারাপ এবং কেবল ডেটা টাইপ যাচাইকরণ, প্যাটার্ন চেক এবং দূষিত ইনজেকশনের পয়েন্টে ডিফেন্সিয়ালি লিখুন। ডিফেন্সিভ প্রোগ্রামিং এমন জিনিসগুলি হওয়া উচিত যা খুব ঘন ঘন ঘটতে পারে যা আপনি নিয়ন্ত্রণ করতে পারবেন না।
2. নেটওয়াক সার্ভিসগুলির জন্য ব্যতিক্রম হ্যান্ডলিং লিখুন যা সময়ে সময়ে ব্যর্থ হতে পারে এবং ব্যবহারকারীর প্রতিক্রিয়ার জন্য কৌতূহলীভাবে পরিচালনা করে। ব্যতিক্রম প্রোগ্রামিং নেটওয়র্কযুক্ত জিনিসগুলির জন্য ব্যবহার করা উচিত যা সময়ে সময়ে ব্যর্থ হতে পারে তবে সাধারণত শক্ত থাকে এবং আপনার প্রোগ্রামটি চালিয়ে যাওয়া দরকার।
3. ইনপুট ডেটা যাচাই করার পরে আপনার অ্যাপ্লিকেশনটিতে ডিফেন্সিয়ালি লিখতে বিরক্ত করবেন না। এটি সময়ের অপচয় এবং আপনার অ্যাপ্লিকেশনকে ব্লুটেট করে। এটি ফুঁকতে দাও কারণ এটি হয় খুব বিরল কিছু যা পরিচালনা করার পক্ষে নয় বা এর অর্থ হল আপনাকে আরও 1 এবং 2 পদক্ষেপটি আরও সাবধানতার সাথে দেখতে হবে।
4. আপনার মূল কোডের মধ্যে ব্যতিক্রম হ্যান্ডলিং কখনই লিখবেন না যা কোনও নেটওয়র্ক ডিভাইসের উপর নির্ভর করে না। এটি করা খারাপ প্রোগ্রামিং এবং পারফরম্যান্সের জন্য ব্যয়বহুল। উদাহরণস্বরূপ, একটি লুপের বাইরে সীমা ছাড়িয়ে যাওয়ার ক্ষেত্রে ট্রাই-ক্যাচ লেখার অর্থ আপনি প্রথম স্থানে লুপটি সঠিকভাবে প্রোগ্রাম করেননি।
5. উপরের পদ্ধতিগুলি অনুসরণ করার পরে এক জায়গায় ব্যতিক্রম ধরা কেন্দ্রীয় ত্রুটি লগিং দিয়ে সবকিছু পরিচালনা করা যাক। আপনি প্রতিটি প্রান্তের কেসটি ধরতে পারবেন না কারণ এটি অসীম হতে পারে, আপনাকে কেবল এমন কোড লিখতে হবে যা প্রত্যাশিত অপারেশন পরিচালনা করে। এজন্য আপনি কেন্দ্রীয় ত্রুটি হ্যান্ডলিংটিকে শেষ অবলম্বন হিসাবে ব্যবহার করেন।
6. টিডিডি দুর্দান্ত কারণ কোনওভাবে ফোলা ছাড়াই আপনার পক্ষে চেষ্টা করা, যার অর্থ আপনাকে স্বাভাবিক অপারেশনের কিছুটা আশ্বাস দেয়।
7. বোনাস পয়েন্ট হ'ল একটি কোড কভারেজ সরঞ্জাম ব্যবহার করা উদাহরণস্বরূপ ইস্তাম্বুল নোডের জন্য ভাল কারণ এটি আপনাকে দেখায় যেখানে আপনি পরীক্ষা করছেন না।
8. সতর্কীকরণ এই সব হয় ডেভেলপার-বন্ধুত্বপূর্ণ ব্যতিক্রম । উদাহরণস্বরূপ, কোনও ভাষা নিক্ষেপ করবে যদি আপনি সিনট্যাক্সটি ভুল ব্যবহার করেন এবং কেন ব্যাখ্যা করেন। আপনার ইউটিলিটি লাইব্রেরিগুলিও আপনার কোডের উপর নির্ভর করে।

এটি বড় দলের দৃশ্যে কাজ করার অভিজ্ঞতা থেকে।

একটি উপমা

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

Comments

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

— mattnz

এটাই হচ্ছে পরীক্ষার জন্য।

— জেসন সেব্রিং

টেস্টিং সব কিছু ধরা দেয় না। আমি এখনও একটি পরীক্ষা স্যুট দেখতে পাই যাতে 100% কোড এবং "পরিবেশগত" কভারেজ রয়েছে।

— মার্জন ভেনেমা

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

— mattnz

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

— ইয়াওবিন

Answer 4

বইটির মূল যুক্তিটি হ'ল কোডটির ব্যতিক্রম সংস্করণটি আরও ভাল কারণ এটি যদি আপনি নিজের ত্রুটি পরীক্ষা করে লেখার চেষ্টা করেন তবে আপনি যা উপেক্ষা করতে পারেন সেটিকে এটি ধরা দেবে।

আমি মনে করি এই বিবৃতিটি কেবল খুব নির্দিষ্ট পরিস্থিতিতেই সত্য - যেখানে আউটপুটটি সঠিক কিনা সেদিকে আপনি খেয়াল রাখেন না।

কোনও সন্দেহ নেই যে ব্যতিক্রম উত্থাপন একটি যথাযথ এবং নিরাপদ অনুশীলন। আপনি যখনই মনে করেন যে প্রোগ্রামের বর্তমান অবস্থায় এমন কিছু আছে যা আপনি (বিকাশকারী হিসাবে) মোকাবেলা করতে পারেন না বা করতে চান না তখনই আপনার উচিত।

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

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

এটি আপনার প্রোগ্রামের প্রকৃতির উপর নির্ভর করে।

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

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

আপনি মনে করতে পারেন যে এই কোডটিতে আপনি দেখতে পাচ্ছেন এমন একমাত্র উপায় ValueErrorহ'ল যদি splitকেবল একটি মান দেওয়া হয় (দুটি পরিবর্তে)। তবে যদি আপনার printবক্তব্যটি পরে এমন কোনও অভিব্যক্তি ব্যবহার শুরু করে যা ValueErrorকিছু শর্তে উত্থাপিত হয়? এটি আপনাকে কিছু রেখাগুলি এড়িয়ে যেতে বাধ্য করবে কারণ তারা মিস করে না :, তবে সেগুলিতে printব্যর্থ হয়। এটি একটি সূক্ষ্ম বাগের উদাহরণ যা আমি আগে উল্লেখ করছি - আপনি কিছুই লক্ষ্য করবেন না, কেবল কিছু লাইন হারাবেন।

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

ব্যতিক্রমগুলি ব্যবহারের পারফরম্যান্সের প্রভাব হিসাবে, ব্যতিক্রমগুলি ঘন ঘন সম্মুখীন না হলে এটি তুচ্ছ (পাইথনে) in

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

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

দ্রষ্টব্য: আমি ধরে নিয়েছি আপনি ন্যায়বিচারের except ValueErrorপরিবর্তে ব্যবহার করবেন except; অন্যরা যেমন উল্লেখ করেছে, এবং বইটি যেমন কয়েকটি পৃষ্ঠায় বলেছে, আপনার কখনই খালি ব্যবহার করা উচিত নয় except।

অন্য দ্রষ্টব্য: যথাযথ অ-ব্যতিক্রম পদ্ধতির splitসন্ধান না করে প্রত্যাবর্তিত মানগুলির সংখ্যা গণনা করা :। যেহেতু এটি কাজ দ্বারা সম্পন্ন পুনরাবৃত্তি পরেরটির, পর্যন্ত খুব ধীর splitও মে প্রায় ডবল সঞ্চালনের সময়।

Answer 5

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

Answer 6

যা কখনও ভাল কাজ করে তা ব্যবহার করুন ..

• কোড পাঠযোগ্যতা এবং দক্ষতার ক্ষেত্রে আপনার নির্বাচিত প্রোগ্রামিংয়ের ভাষা
• আপনার দল এবং সম্মত কোড কনভেনশনগুলির সেট

ব্যতিক্রম হ্যান্ডলিং এবং ডিফেন্সিভ প্রোগ্রামিং উভয়ই একই অভিপ্রায়টি প্রকাশ করার বিভিন্ন উপায়।

Answer 7

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

যাহোক...

আমি আপনার বর্তমান রেফারেন্স ব্যবহার করে যত্নবান হতে হবে। তাদের কোডটি নিয়ে বেশ কয়েকটি সুস্পষ্ট সমস্যা:

1. ফাইল বর্ণনাকারী ফাঁস হয়েছে। সিপথনের আধুনিক সংস্করণগুলি (একটি নির্দিষ্ট পাইথন ইন্টারপ্রেটার) আসলে এটি বন্ধ করে দেবে, কারণ এটি একটি বেনামে থাকা বস্তু যা লুপ চলাকালীন কেবলমাত্র সুযোগ (জিসি লুপের পরে এটি অনুগ্রহ করবে)। তবে, অন্যান্য দোভাষী না এই গ্যারান্টি আছে। তারা বর্ণনাকারী সরাসরি ফুটো করতে পারে। withপাইথনে ফাইলগুলি পড়ার সময় আপনি প্রায় সর্বদা আইডিয়মটি ব্যবহার করতে চান : ব্যতিক্রম খুব কমই রয়েছে। এটি তাদের মধ্যে একটি নয়।
2. পোকেমন ব্যতিক্রম হ্যান্ডলিংটি ত্রুটিগুলি মাস্ক করার সাথে সাথে তা ভঙ্গুর করা হয় (অর্থাত্ exceptএকটি বিবৃতি যা একটি নির্দিষ্ট ব্যতিক্রম ধরা দেয় না)
3. নীট: টুপল আনপ্যাকিংয়ের জন্য আপনার প্যারেন দরকার নেই। শুধু করতে পারেনrole, lineSpoken = eachLine.split(":",1)

আইভিসি এর এবং ইএএফপি সম্পর্কে একটি ভাল উত্তর রয়েছে তবে এটি বিবরণী ফাঁস করছে।

এলবিওয়াইএল সংস্করণটি অবশ্যই ইএএফপি সংস্করণের মতো পারফরম্যান্ট নয়, তাই বলে যে ব্যতিক্রম নিক্ষেপ করা "পারফরম্যান্সের ক্ষেত্রে ব্যয়বহুল" বলা স্পষ্টতই মিথ্যা। এটি আপনি প্রক্রিয়াকরণের স্ট্রিংয়ের ধরণের উপর নির্ভর করে:

In [33]: def lbyl(lines):
    ...:     for line in lines:
    ...:         if line.find(":") != -1:
    ...:             # Nuke the parens, do tuple unpacking like an idiomatic Python dev.
    ...:             role, lineSpoken = line.split(":",1)
    ...:             # no print, since output is obnoxiously long with %timeit
    ...:

In [34]: def eafp(lines):
    ...:     for line in lines:
    ...:         try:
    ...:             # Nuke the parens, do tuple unpacking like an idiomatic Python dev.
    ...:             role, lineSpoken = eachLine.split(":",1)
    ...:             # no print, since output is obnoxiously long with %timeit
    ...:         except:
    ...:             pass
    ...:

In [35]: lines = ["abc:def", "onetwothree", "xyz:hij"]

In [36]: %timeit lbyl(lines)
100000 loops, best of 3: 1.96 µs per loop

In [37]: %timeit eafp(lines)
100000 loops, best of 3: 4.02 µs per loop

In [38]: lines = ["a"*100000 + ":" + "b", "onetwothree", "abconetwothree"*100]

In [39]: %timeit lbyl(lines)
10000 loops, best of 3: 119 µs per loop

In [40]: %timeit eafp(lines)
100000 loops, best of 3: 4.2 µs per loop

Answer 8

মূলত ব্যতিক্রম হ্যান্ডলিং OOP ভাষার জন্য আরও উপযুক্ত বলে মনে করা হয়।

দ্বিতীয় বিষয় হল কর্মক্ষমতা, কারণ আপনাকে eachLine.findপ্রতিটি লাইনের জন্য নির্বাহ করতে হবে না ।

Comments

-1: কম্বল বিধিগুলির জন্য পারফরম্যান্স অত্যন্ত দুর্বল কারণ।

— mattnz

না, ব্যতিক্রমগুলি সম্পূর্ণরূপে ওওপির সাথে সম্পর্কিত নয়।

— পাব্বি

Answer 9

আমি মনে করি রক্ষণাত্মক প্রোগ্রামিং কর্মক্ষমতা ক্ষতি করে। আপনি যে ব্যতিক্রমগুলি পরিচালনা করতে চলেছেন সেগুলিও আপনার ধরা উচিত, কীভাবে পরিচালনা করতে হয় না তার ব্যতিক্রম নিয়ে রানটাইম চুক্তি করুন let

Comments

তবুও anotehr -1 পাঠযোগ্যতা, রক্ষণাবেক্ষণ ব্লক ব্লেম উপর কর্মক্ষমতা সম্পর্কে উদ্বিগ্ন জন্য। পারফরম্যান্স কোনও কারণ নয়।

— mattnz

আমি কি জানতে পারি আপনি ব্যাখ্যা না করেই কেন -1 বিতরণ করছেন? ডিফেন্সিভ প্রোগ্রামিং মানে কোডের আরও লাইন, এর অর্থ দরিদ্র কর্মক্ষমতা। স্কোর শট করার আগে কারও কি ব্যাখ্যা করা দরকার?

— মনোজ

@ মনোজ: আপনি যদি কোনও প্রোফাইলারের সাথে পরিমাপ না করে এবং অগ্রহণযোগ্যভাবে ধীর হতে কোডের একটি ব্লক না পান তবে পারফরম্যান্সের অনেক আগে পঠনযোগ্যতা এবং রক্ষণাবেক্ষণের কোড।

— দেনিথ

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

— mattnz

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

— mattnz