আমাদের ত্রুটি ছুঁড়ে দেওয়া উচিত কিনা তা নির্দেশ করার জন্য একটি পতাকা রয়েছে


64

আমি সম্প্রতি বেশ কয়েকটি পুরানো বিকাশকারী (প্রায় 50+ বছর বয়সী) এর সাথে এক জায়গায় কাজ শুরু করেছি। তারা বিমান চালনার বিষয়ে সমালোচনামূলক অ্যাপ্লিকেশনগুলিতে কাজ করেছে যেখানে সিস্টেমটি নামতে পারে না। ফলস্বরূপ পুরানো প্রোগ্রামার এইভাবে কোড করতে ঝোঁক।

তিনি কোনও ব্যতিক্রম ছোঁড়া উচিত কিনা তা নির্দেশ করার জন্য তিনি বস্তুগুলিতে একটি বুলিয়ান রাখেন।

উদাহরণ

public class AreaCalculator
{
    AreaCalculator(bool shouldThrowExceptions) { ... }
    CalculateArea(int x, int y)
    {
        if(x < 0 || y < 0)
        {
            if(shouldThrowExceptions) 
                throwException;
            else
                return 0;
        }
    }
}

(আমাদের প্রকল্পে পদ্ধতিটি ব্যর্থ হতে পারে কারণ আমরা এমন একটি নেটওয়ার্ক ডিভাইস ব্যবহার করার চেষ্টা করছি যা সেই সময়ে উপস্থিত হতে পারে না area ক্ষেত্রের উদাহরণটি ব্যতিক্রম পতাকার একটি উদাহরণ মাত্র)

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

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

ব্যতিক্রমগুলি পরিচালনা করার এটি কি ভাল উপায়?

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

2 সম্পাদনা করুন : আরও প্রসঙ্গে, আমাদের ক্ষেত্রে পদ্ধতিটি একটি কার্ড কার্ড পুনরায় সেট করতে বলা হয়। সমস্যাটি দেখা দেয় যখন নেটওয়ার্ক কার্ডটি সংযোগ বিচ্ছিন্ন হয়ে যায় এবং পুনরায় সংযোগ স্থাপন করা হয়, এটি একটি আলাদা আইপি ঠিকানা বরাদ্দ করা হয়, সুতরাং রিসেটটি একটি ব্যতিক্রম ছুঁড়ে দেবে কারণ আমরা পুরানো আইপি দিয়ে হার্ডওয়্যারটি পুনরায় সেট করার চেষ্টা করব।


22
c # এর এই পার্স-পার্স প্যাটারের জন্য একটি সম্মেলন রয়েছে। আরও তথ্য: ডকস.মাইক্রোসফট. / en-us / dotnet / standard / design-guidlines/… পতাকাটি এই প্যাটার্নের সাথে মেলে না।
পিটার

18
এটি মূলত একটি নিয়ন্ত্রণ পরামিতি এবং এটি অভ্যন্তরীণ পদ্ধতিগুলি কার্যকর করে কীভাবে পরিবর্তন করে। পরিস্থিতি নির্বিশেষে এটি খারাপ। martinfowler.com/bliki/FlagArgument.html , softwareengineering.stackexchange.com/questions/147977/... , medium.com/@amlcurran/...
BIC

1
পিটারের চেষ্টা-পার্সে মন্তব্য ছাড়াও, এখানে ভেক্সিং
এয়ারস্লিপার্ট

2
"এইভাবে আমরা কোনও ব্যতিক্রম ছোঁড়াতে চাই না (এবং এটি পরিচালনা করতে চাই না?) এবং ব্যবহারকারীর পক্ষে এটি ঠিকঠাক হলে প্রোগ্রামটি নামিয়ে ফেলতে হবে" - আপনি কি জানেন যে সঠিকভাবে ব্যতিক্রমগুলি ধরতে পারবেন?
ব্যবহারকারী 253751

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

উত্তর:


74

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

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

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


1
@ কির্ক এটি চিত্তাকর্ষকটি কীভাবে কেবল 3 বা 4 লাইনে একক দায়িত্বের নীতি লঙ্ঘন করতে সক্ষম হয়েছিল। এটাই আসল সমস্যা। এছাড়াও, তিনি যে সমস্যার কথা বলছেন (প্রোগ্রামার প্রতিটি লাইনে ত্রুটির পরিণতি সম্পর্কে চিন্তা করতে ব্যর্থ হয়) তা সর্বদা চেক না করা ব্যতিক্রম এবং কেবল কখনও কখনও পরীক্ষিত ব্যতিক্রমগুলির সাথে একটি সম্ভাবনা। আমি মনে করি আমি চেক করা ব্যাতিক্রমগুলির বিরুদ্ধে কখনও তৈরি সমস্ত যুক্তি দেখেছি এবং এর মধ্যে একটিও বৈধ নয়।
TKK

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

1
@ জেআরহ হ্যাঁ, ভাল লাগবে যদি কোনও কিছু .NET- র মধ্যে কিছু ব্যতিক্রমী সুরক্ষা দেয় তবে কীভাবে টাইপস্ক্রিপ্টটি জেএসে সুরক্ষা টাইপ করে lud
TKK

47

ব্যতিক্রমগুলি পরিচালনা করার এটি কি ভাল উপায়?

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

সাধারণভাবে, যখন আমরা ক্লাসগুলি এবং তাদের এপিআইগুলি ডিজাইন করি তখন আমাদের এটি বিবেচনা করা উচিত

  1. ক্লাসের একাধিক উদাহরণ হতে পারে একই সাথে একই প্রোগ্রামে প্রায় একই সময়ে বিভিন্ন কনফিগারেশনগুলি ভেসে ওঠে এবং,

  2. নির্ভরতা ইনজেকশন এবং অন্যান্য যে কোনও প্রোগ্রামিং অনুশীলনের কারণে, একজন গ্রাহক গ্রাহক বস্তুগুলি তৈরি করতে পারেন এবং অন্যটিকে তাদের ব্যবহারের হাতে তুলে দিতে পারেন - তাই প্রায়শই আমাদের অবজেক্ট ক্রিয়েটার এবং অবজেক্ট ব্যবহারকারীদের মধ্যে বিচ্ছেদ হয়।

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

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

উভয় এপিআই সরবরাহ করার জন্য, আপনি দুটি পৃথক শ্রেণি সরবরাহ করার চেয়ে অনেক বেশি উন্নত এবং বেশি স্বাভাবিক - একটি যা সর্বদা ত্রুটির দিকে ছুঁড়ে যায় এবং একটি যা সর্বদা ত্রুটিতে 0 প্রদান করে, বা একক শ্রেণীর সাথে দুটি পৃথক পদ্ধতি সরবরাহ করে। এইভাবে গ্রাহক ক্লায়েন্ট সহজে ত্রুটিগুলি কীভাবে চেক করবেন এবং পরিচালনা করবেন তা জানতে পারবেন can

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


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

আপনার কোড বেসটি একবার দেখুন এবং দেখুন যে কোনও ভেরিয়েবল (বা অ-ধ্রুবক এক্সপ্রেশন) কনস্ট্রাক্টরে বুলিয়ান কনফিগারেশন প্যারামিটারের জন্য ব্যবহৃত হয় কিনা! আমি এটাকে সন্দেহ করি.


এবং আরও বিবেচনা হ'ল অঞ্চলটি কেন গণনা করতে ব্যর্থ হতে পারে তা জিজ্ঞাসা করা। কন্সট্রাক্টর নিক্ষেপ করা সেরা হতে পারে, যদি গণনা করা যায় না। তবে, যদি আপনি না জানেন যে অবজেক্টটি আরও সূচনা না করা পর্যন্ত গণনা করা যায় কিনা, তবে সম্ভবত সেই রাজ্যগুলিকে আলাদা করার জন্য বিভিন্ন শ্রেণি ব্যবহারের কথা বিবেচনা করুন (গণনা ক্ষেত্রের তুলনায় প্রস্তুত অঞ্চল তৈরির জন্য প্রস্তুত নয়)।

আমি পড়েছি যে আপনার ব্যর্থতার পরিস্থিতি রিমোটিংয়ের দিকে ভিত্তি করে, সুতরাং এটি প্রয়োগ নাও করতে পারে; কিছু খাদ্যের জন্য চিন্তা.


কীভাবে চালিয়ে যেতে হবে তা নির্ধারণ করার জন্য কলারের দায়িত্ব হওয়া উচিত নয়?

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


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

আনেক্সেক্স কে এম, সি 99 এবং সি ++ আইওস্ট্রিমগুলির জন্য চাপ দেয় এমন এপিআইগুলির উদাহরণ যেখানে একটি হুক বা পতাকা ব্যর্থতার প্রতিক্রিয়াটিকে আমূল পরিবর্তন করে।
Deduplicator

37

তারা বিমান চালনার বিষয়ে সমালোচনামূলক অ্যাপ্লিকেশনগুলিতে কাজ করেছে যেখানে সিস্টেমটি নামতে পারে না। ফলস্বরূপ ...

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

  • ব্যতিক্রমগুলি কমপক্ষে বা কঠোরভাবে সঠিকভাবে পরিচালনা করা হয় না

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

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

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

  • যখন "ব্ল্যাক বক্স" উপাদানগুলি ব্যবহার করে এবং প্রোগ্রামটির বিশ্বব্যাপী আচরণের কথা মাথায় রেখে ব্যতিক্রমগুলি প্রত্যাশা করতে এবং তার সাথে মোকাবিলা করতে প্রশিক্ষণ দিন।

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

    CalculateArea(int x, int y, out ErrorCode err)

    সুতরাং কলকারীর পক্ষে কাজটি উপেক্ষা করা সত্যিই কঠিন হয়ে যায় যাতে ফাংশন ব্যর্থ হতে পারে। তবে এটি সি # তে আইএমএইচও অত্যন্ত কুৎসিত; এটি সি এর একটি পুরানো ডিফেন্সিভ প্রোগ্রামিং কৌশল যেখানে কোনও ব্যতিক্রম নেই এবং আজকাল এটি সাধারণত কাজ করার প্রয়োজন হবে না।


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

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

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

4
এই. আপনি যদি প্রোগ্রামটি ক্র্যাশ করার সামর্থ্য না রাখেন তবে নীরবেই ভুল উত্তর দেওয়ার পক্ষে আপনি সামর্থ্য রাখতে পারবেন না। সঠিক উত্তরটি হ'ল সকল ক্ষেত্রে উপযুক্ত ব্যতিক্রম পরিচালনা করা । একটি ওয়েবসাইট, একটি বিশ্বব্যাপী হ্যান্ডলার রয়েছে যা 500 মধ্যে অপ্রত্যাশিত ত্রুটি পরিবর্তন করে এছাড়াও আপনি একটি থাকার মত, আরো নির্দিষ্ট পরিস্থিতিতে জন্য অতিরিক্ত হ্যান্ডেলার থাকতে পারে এর মানে হল যে জন্য try/ catchযদি আপনি প্রক্রিয়াকরণ প্রয়োজন যদি এক উপাদান ব্যর্থ অব্যাহত রাখার জন্য একটি লুপ ভিতরে।
jpmc26

2
ভুল ফলাফল পাওয়া সর্বদা সবচেয়ে খারাপ ধরণের ব্যর্থতা; এটি আমাকে অপ্টিমাইজেশান সম্পর্কে নিয়মের কথা মনে করিয়ে দেয়: "আপনার অনুকূলিতকরণের আগে এটি সঠিক করুন, কারণ ভুল উত্তর দ্রুত পাওয়া এখনও কারও উপকারে আসে না।"
টবি স্পিড

13

লেখার ইউনিট পরীক্ষাগুলি কিছুটা জটিল হয়ে যায় কারণ আপনাকে প্রতিবার ব্যতিক্রমের পতাকাটির জন্য পরীক্ষা করতে হয়।

এন প্যারামিটার সহ যে কোনও ফাংশন এন -1 পরামিতিগুলির সাথে একের চেয়ে পরীক্ষা করা আরও শক্ত হতে চলেছে । এটিকে অযৌক্তিকভাবে প্রসারিত করুন এবং যুক্তিটি হয়ে যায় যে ফাংশনগুলিতে মোটামুটি পরামিতি থাকা উচিত নয় কারণ এটি তাদের পরীক্ষা করা সবচেয়ে সহজ করে তোলে।

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

এছাড়াও, যদি কিছু ভুল হয়ে যায় তবে আপনি এখনই জানতে চান না?

এটি আপনার ভুল সংজ্ঞা উপর নির্ভর করে। প্রশ্নের উদাহরণটি ভুল হিসাবে সংজ্ঞা দেয় "শূন্যের চেয়ে কম মাত্রার দেওয়া এবং shouldThrowExceptionsএটি সত্য" is shouldThrowExceptionsমিথ্যা হলে শূন্যের চেয়ে কম না হলে একটি মাত্রা দেওয়া হচ্ছে কারণ স্যুইচ বিভিন্ন আচরণ প্রেরণা দেয়। এটি, বেশ সরলভাবে, ব্যতিক্রমী পরিস্থিতি নয়।

এখানে আসল সমস্যাটি হ'ল স্যুইচটি খারাপ নামকরণ করা হয়েছে কারণ এটি ফাংশনটি কী করে তা বর্ণনামূলক নয়। এটির মতো আরও ভাল নাম দেওয়া থাকলে treatInvalidDimensionsAsZeroআপনি কি এই প্রশ্নটি জিজ্ঞাসা করতেন?

কীভাবে চালিয়ে যেতে হবে তা নির্ধারণ করার জন্য কলারের দায়িত্ব হওয়া উচিত নয়?

কলার কীভাবে চালিয়ে যেতে হয় তা নির্ধারণ করে । এই ক্ষেত্রে এটি সেট করা বা সাফ করার মাধ্যমে সময়ের আগেই shouldThrowExceptionsকাজ করে এবং ফাংশনটি তার রাজ্য অনুযায়ী আচরণ করে।

উদাহরণটি একটি প্যাথলজিক্যালি-সহজ একটি কারণ এটি একটি একক গণনা করে এবং ফেরত দেয়। যদি আপনি এটিকে কিছুটা জটিল করেন যেমন সংখ্যার তালিকার বর্গমূলের সমষ্টি গণনা করা, ব্যতিক্রম ছোঁড়া কলকারীদের সমস্যাগুলি সমাধান করতে পারে যা তারা সমাধান করতে পারে না। যদি আমি একটি তালিকায় পাস করি [5, 6, -1, 8, 12]এবং ফাংশনটি একটি ব্যতিক্রম ছুঁড়ে ফেলে -1তবে ফাংশনটি চালিয়ে যেতে বলার উপায় নেই কারণ এটি ইতিমধ্যে বাতিল করে যোগফল ফেলে দেবে। যদি তালিকাটি একটি বিশাল ডেটা সেট থাকে তবে ফাংশনটি কল করার আগে কোনও নেতিবাচক সংখ্যা ছাড়াই একটি অনুলিপি তৈরি করা অবৈজ্ঞানিক হতে পারে, তাই আমি আগে থেকেই বলতে বাধ্য হচ্ছি যে "অবৈধভাবে এগুলি উপেক্ষা করুন" আকারে অবৈধ সংখ্যাগুলি কীভাবে আচরণ করা উচিত should "স্যুইচ করুন বা সম্ভবত কোনও ল্যাম্বডা সরবরাহ করুন যা সিদ্ধান্ত নেওয়ার জন্য ডাকা হয়।

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

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

এবং সেই অনেক বয়স্ক প্রোগ্রামারদের একজন হিসাবে, আমি আপনাকে অনুরোধ করব যে আপনি বিনয়ের সাথে আমার লন থেকে চলে যান। ;-)


আমি সম্মত হই যে নামকরণ এবং অভিপ্রায় অত্যন্ত গুরুত্বপূর্ণ এবং এক্ষেত্রে যথাযথ পরামিতি নামগুলি টেবিলগুলি সত্যই ঘুরিয়ে দিতে our program needs to do 1 thing, show data to user. Any other exception that doesn't stop us from doing so should be ignoredপারে , তবে +1, তবে 1. মানসিকতা ব্যবহারকারীর ভুল ডেটার উপর ভিত্তি করে সিদ্ধান্ত গ্রহণ করতে পারে (কারণ আসলে প্রোগ্রামটি করা দরকার 1 টি জিনিস - ব্যবহারকারীকে অবগত সিদ্ধান্ত নিতে সহায়তা করার জন্য) ২. অনুরূপ ক্ষেত্রে bool ExecuteJob(bool throwOnError = false)সাধারণত চূড়ান্ত ত্রুটিযুক্ত থাকে এবং কোড পড়ে থাকে যা কেবল এটি পড়েই যুক্তিযুক্ত হতে পারে।
ইউজিন পডস্কাল

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

উত্তম উত্তর, আমি মনে করি এই যুক্তিটি কেবল ওপি'র চেয়ে অনেক বিস্তৃত পরিস্থিতিতে প্রযোজ্য। বিটিডাব্লু, সিপিসির নতুনটির ঠিক এই কারণগুলির জন্য একটি থ্রো / নো-থ্রো সংস্করণ রয়েছে। আমি জানি কিছু ছোট পার্থক্য রয়েছে তবে ...
drjpizzle

8

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

এগুলি প্রায়শই আপনার কাছে প্রত্যাশিত জিনিসগুলির সাথে সম্পর্কিত:

  • গিটের জন্য, ভুল উত্তরটি তুলনামূলকভাবে খুব খারাপ হতে পারে: নেওয়া-নেওয়া-দীর্ঘ / গর্ভপাত / ঝুলানো বা ক্র্যাশ করা (যা কার্যকরভাবে অ-ইস্যু সম্পর্কিত, বলুন, দুর্ঘটনাক্রমে চেক-ইন কোড পরিবর্তন করে)।

    তবে: একটি জি-ফোর্স গণনা স্টলিং থাকা এবং একটি বায়ু-গতি গণনা রোধ করা একটি উপকরণ প্যানেলের জন্য সম্ভবত গ্রহণযোগ্য নয়।

কিছু কম স্পষ্ট:

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

  • প্রদর্শিতভাবে নিরাপদ হওয়া তুলনামূলকভাবে গুরুত্বপূর্ণ। তারা যে উত্সটি কিনছেন সেগুলি নিরাপদ কিনা তা নিয়ে অনেক গ্রাহকই যুক্তি দেখবেন না। আপনি অন্যদিকে বিমানের বাজারে থাকলে ...

এটি আপনার উদাহরণে কীভাবে প্রযোজ্য:

আমি জানি না। নিরাপত্তা সমালোচনামূলক কোড গ্রহণ করা হচ্ছে "প্রডাকশন কোডে নো-ওয়ান থ্রো" এর মতো নেতৃত্বের নিয়ম থাকতে পারে এমন অনেকগুলি চিন্তার প্রক্রিয়া রয়েছে যা আরও সাধারণ পরিস্থিতিতে বেশ নির্বোধ হতে পারে।

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

বলেন যে সবাই এটা আমার কাছে একটি বাচ্চা সন্দেহভাজন দেখায় কিন্তু :

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


7

কখনও কখনও একটি ব্যতিক্রম নিক্ষেপ করা সর্বোত্তম পদ্ধতি নয়। কমপক্ষে আনওয়াইন্ডিং স্ট্যাকের কারণে নয়, তবে কখনও কখনও ব্যতিক্রম ধরা সমস্যাযুক্ত হয়, বিশেষত ভাষা বা ইন্টারফেস seams সহ।

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

এটি সমৃদ্ধ তথ্য-প্রকারের পদক্ষেপে পদক্ষেপ নিতে বাধ্য করা উচিত নয়। আপনার অঞ্চলের উদাহরণে কিছু কল্পনা করুন var area_calc = new AreaCalculator(); var volume = area_calc.CalculateArea(x, y) * z;। দরকারী volumeমনে হচ্ছে এমন অঞ্চলটি গভীরতার সাথে গুণিত হওয়া উচিত - এটি কিউব, সিলিন্ডার ইত্যাদি হতে পারে ...

তবে কি যদি এলাকা_ক্যালক পরিষেবা বন্ধ ছিল? তারপরে area_calc .CalculateArea(x, y)একটি ত্রুটিযুক্ত সমৃদ্ধ ডেটাটাইপ ফিরিয়ে দিল। এটি দিয়ে গুণ করা বৈধ z? এটি একটি ভাল প্রশ্ন। আপনি অবিলম্বে ব্যবহারকারীদের চেকিং পরিচালনা করতে বাধ্য করতে পারেন। এটি ত্রুটি হ্যান্ডলিংয়ের সাথে যুক্তিটিকে ভেঙে দেয়।

var area_calc = new AreaCalculator();
var area_result = area_calc.CalculateArea(x, y);
if (area_result.bad())
{
    //handle unhappy path
}
var volume = area_result.value() * z;

বনাম

var area_calc = new AreaCalculator();
var volume = area_calc.CalculateArea(x, y) * z;
if (volume.bad())
{
    //handle unhappy path
}

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

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

পর্যায়ক্রমে volumeকেবল একটি সরল ডাটা টাইপ হতে পারে - কেবল একটি সংখ্যা, তবে ত্রুটির শর্তটি কী ঘটে? এটি হতে পারে যে মানটি সুখী অবস্থায় থাকলে স্পষ্টত রূপান্তরিত হয়। এটি যদি অসুখী অবস্থায় থাকে তবে এটি একটি ডিফল্ট / ত্রুটির মানটি ফিরিয়ে আনতে পারে (ক্ষেত্র 0 বা -1 যুক্তিসঙ্গত বলে মনে হতে পারে)। পর্যায়ক্রমে এটি ইন্টারফেস / ভাষার সীমানার এই দিকে একটি ব্যতিক্রম ছুঁড়ে ফেলতে পারে।

... foo() {
   var area_calc = new AreaCalculator();
   return area_calc.CalculateArea(x, y) * z;
}
var volume = foo();
if (volume <= 0)
{
    //handle error
}

বনাম

... foo() {
   var area_calc = new AreaCalculator();
   return area_calc.CalculateArea(x, y) * z;
}

try { var volume = foo(); }
catch(...)
{
    //handle error
}

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

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

চূড়ান্ত সমাধানটি এমন এক হবে যা সমস্ত পরিস্থিতিতে অনুমতি দেয় (কারণের মধ্যে)।

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

কিছুটা এইরকম:

Rich::value_type value_or_default(Rich&, Rich::value_type default_value = ...);
bool bad(Rich&);
...unhappy path report... bad_state(Rich&);
Rich& assert_not_bad(Rich&);
class Rich
{
public:
   typedef ... value_type;

   operator value_type() { assert_not_bad(*this); return ...value...; }
   operator X(...) { if (bad(*this)) return ...propagate badness to new value...; /*operate and generate new value*/; }
}

//check
if (bad(x))
{
    var report = bad_state(x);
    //handle error
}

//rethrow
assert_not_bad(x);
var result = (assert_not_bad(x) + 23) / 45;

//propogate
var y = x * 23;

//implicit throw
Rich::value_type val = x;
var val = ((Rich::value_type)x) + 34;
var val2 = static_cast<Rich::value_type>(x) % 3;

//default value
var defaulted = value_or_default(x);
var defaulted_to = value_or_default(x, 55);

@ টবিস্পাইট ফেয়ার পর্যাপ্ত, এই জিনিসগুলি প্রসঙ্গে সংবেদনশীল এবং এর পরিধি রয়েছে।
Kain0_0

আমি মনে করি যে এখানে সমস্যা হ'ল 'assert_not_bad' ব্লক। আমি মনে করি যে মূল কোডটি সমাধান করার চেষ্টা করার সাথে সাথে এগুলি একই জায়গায় থাকবে। পরীক্ষার ক্ষেত্রে এগুলি লক্ষ্য করা দরকার, তবে, যদি তারা সত্যই দৃser় হয় তবে তাদের একটি সত্যিকারের বিমানে উত্পাদনের আগে ছিনিয়ে নেওয়া উচিত। অন্যথায় কিছু দুর্দান্ত পয়েন্ট।
drjpizzle

@ ডিআরজপিজল আমি যুক্তি দিয়ে বলব যে যদি পরীক্ষার জন্য কোনও প্রহরী যোগ করা যথেষ্ট গুরুত্বপূর্ণ ছিল, উত্পাদন চালানোর সময় প্রহরীটিকে যথাযথভাবে ছেড়ে দেওয়া যথেষ্ট গুরুত্বপূর্ণ। গার্ডের উপস্থিতি নিজেই সন্দেহকে বোঝায়। যদি আপনি পরীক্ষার সময় কোডটি রক্ষা করার জন্য যথেষ্ট সন্দেহ করেন তবে আপনি কোনও প্রযুক্তিগত কারণে এটিতে সন্দেহ করছেন। অর্থাত্ শর্তটি বাস্তবে ঘটতে পারে / করতে পারে। কার্যকর পরীক্ষাগুলি প্রমাণ করে না যে শর্তটি কখনই উত্পাদনে পৌঁছাবে না। তার মানে হল যে একটি জ্ঞাত শর্ত রয়েছে, এটি ঘটতে পারে, এটি কোনওভাবে কোনও কোনও জায়গায় পরিচালনা করা দরকার। আমি মনে করি এটি কীভাবে পরিচালিত হয়, সমস্যা।
Kain0_0

3

আমি সি ++ এর দৃষ্টিকোণ থেকে উত্তর দেব। আমি নিশ্চিত যে সমস্ত মূল ধারণাটি সি # তে স্থানান্তরযোগ্য।

দেখে মনে হচ্ছে আপনার পছন্দসই স্টাইলটি "সর্বদা ব্যতিক্রম ছোঁড়া":

int CalculateArea(int x, int y) {
    if (x < 0 || y < 0) {
        throw Exception("negative side lengths");
    }
    return x * y;
}

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

সুতরাং কিছু লাইব্রেরি (যেমন <filesystem>) সি ++ কে "ডুয়াল এপিআই" বলে ডাকে বা সি # কী Try-Parseপ্যাটার্নটি কল করে তা ব্যবহার করে (ধন্যবাদ পিটার টিপটির জন্য!)

int CalculateArea(int x, int y) {
    if (x < 0 || y < 0) {
        throw Exception("negative side lengths");
    }
    return x * y;
}

bool TryCalculateArea(int x, int y, int& result) {
    if (x < 0 || y < 0) {
        return false;
    }
    result = x * y;
    return true;
}

int a1 = CalculateArea(x, y);
int a2;
if (TryCalculateArea(x, y, a2)) {
    // use a2
}

আপনি এখনই "দ্বৈত এপিআই" দিয়ে সমস্যাটি দেখতে পাচ্ছেন: প্রচুর কোড ডুপ্লিকেশন, ব্যবহারকারীদের জন্য কোনও গাইডলাইন নেই যে "এপিআই" সঠিকভাবে ব্যবহার করা উচিত এবং ব্যবহারকারীকে অবশ্যই দরকারী ত্রুটি বার্তাগুলির মধ্যে কঠোর পছন্দ করতে হবে ( CalculateArea) এবং গতি ( TryCalculateArea) কারণ দ্রুততম সংস্করণটি আমাদের দরকারী "negative side lengths"ব্যতিক্রম নিয়ে যায় এবং এটিকে অকেজোতে পরিণত করে false- "কিছু ভুল হয়েছে, আমাকে কী জিজ্ঞাসা করবেন না কোথায়"। (কিছু দ্বৈত API গুলি যেমন, আরো ভাবপূর্ণ ত্রুটি টাইপ ব্যবহার int errnoসি ++ এর বা std::error_code, কিন্তু যে এখনও আপনাদের বলছি না যেখানে ত্রুটি ঘটেছে - শুধু এটা করেনি কোথাও দেখা যায়।)

আপনার কোডটি কীভাবে আচরণ করা উচিত তা যদি আপনি সিদ্ধান্ত নিতে না পারেন তবে আপনি সর্বদা কলারের কাছে সিদ্ধান্তটিকে লাথি মারতে পারেন!

template<class F>
int CalculateArea(int x, int y, F errorCallback) {
    if (x < 0 || y < 0) {
        return errorCallback(x, y, "negative side lengths");
    }
    return x * y;
}

int a1 = CalculateArea(x, y, [](auto...) { return 0; });
int a2 = CalculateArea(x, y, [](int, int, auto msg) { throw Exception(msg); });
int a3 = CalculateArea(x, y, [](int, int, auto) { return x * y; });

এটি আপনার সহকর্মী মূলত যা করছে; ব্যতীত তিনি "ত্রুটি হ্যান্ডলার" কে বৈশ্বিক পরিবর্তনশীল হিসাবে চিহ্নিত করছেন:

std::function<int(const char *)> g_errorCallback;

int CalculateArea(int x, int y) {
    if (x < 0 || y < 0) {
        return g_errorCallback("negative side lengths");
    }
    return x * y;
}

g_errorCallback = [](auto) { return 0; };
int a1 = CalculateArea(x, y);
g_errorCallback = [](const char *msg) { throw Exception(msg); };
int a2 = CalculateArea(x, y);

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

তদুপরি, আপনার সহকর্মী অকারণে সম্ভাব্য ত্রুটি পরিচালনার আচরণের সংখ্যা সীমিত করছেন। লাম্বদা যে কোনও ত্রুটি-হ্যান্ডলিংয়ের অনুমতি দেওয়ার পরিবর্তে , তিনি মাত্র দুটি বিষয়ে সিদ্ধান্ত নিয়েছেন:

bool g_errorViaException;

int CalculateArea(int x, int y) {
    if (x < 0 || y < 0) {
        return g_errorViaException ? throw Exception("negative side lengths") : 0;
    }
    return x * y;
}

g_errorViaException = false;
int a1 = CalculateArea(x, y);
g_errorViaException = true;
int a2 = CalculateArea(x, y);

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

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

int CalculateArea(int x, int y) {
    if (x < 0 || y < 0) {
#ifdef NEXCEPTIONS
        return 0;
#else
        throw Exception("negative side lengths");
#endif
    }
    return x * y;
}

// Now these two function calls *must* have the same behavior,
// which is a nice property for a program to have.
// Improves understandability.
//
int a1 = CalculateArea(x, y);
int a2 = CalculateArea(x, y);

যেভাবে এইভাবে কাজ করে তার উদাহরণ হ'ল সি এবং সি ++ এর assertম্যাক্রো যা প্রিপ্রসেসর ম্যাক্রোর উপর এর আচরণকে শর্ত করে NDEBUG


এক একটি ফেরৎ যদি std::optionalথেকে TryCalculateArea()পরিবর্তে, এটি একটি কম্পাইল-টাইম-ফ্ল্যাগ সঙ্গে একটি একক ফাংশন-টেমপ্লেটে দ্বৈত ইন্টারফেস দুটি অংশে বাস্তবায়ন ঐক্যবদ্ধ করার সহজ।
উত্সাহক

@ উত্সাহক: সম্ভবত একটি দিয়ে std::expected। ন্যায়সঙ্গতভাবে std::optional, যদি না আমি আপনার প্রস্তাবিত সমাধানটিকে ভুল বুঝি, তবে এটি যা বলেছিলাম তা থেকে এখনও ক্ষতিগ্রস্থ হবে: ব্যবহারকারীর অবশ্যই দরকারী ত্রুটি বার্তাগুলি এবং গতির মধ্যে কঠোর পছন্দ করতে হবে, কারণ দ্রুততম সংস্করণটি আমাদের দরকারী "negative side lengths"ব্যতিক্রম নিয়ে যায় এবং এটিকে নিরর্থক করে তোলে false- " কিছু ভুল হয়েছে, আমাকে জিজ্ঞাসা করবেন না কোথায় বা কোথায় ""
কুক্সপ্লসোন

এই কারণেই লিবিসি ++ <ফাইলসিসটেম> ওপির সহকর্মীর প্যাটার্নের খুব কাছাকাছি কিছু করে: এটি std::error_code *ecএপিআইয়ের প্রতিটি স্তরের মধ্য দিয়ে সমস্ত পথে পাইপ দেয় এবং তারপরে নীচের অংশে নৈতিক সমতুল্য হয় if (ec == nullptr) throw something; else *ec = some error code। (এটি প্রকৃত ifনামক কিছুকে বিমূর্ত করে তোলে ErrorHandler, তবে এটি একই বেসিক ধারণা))
কুক্সপ্লসোন

ওয়েল এটি ছোঁড়া ছাড়াই বর্ধিত ত্রুটি-তথ্য রাখার একটি বিকল্প হবে। সম্ভাব্য অতিরিক্ত ব্যয়ের উপযুক্ত হতে পারে বা নাও পারা যায়।
উত্সাহক

1
এই উত্তরে এতগুলি ভাল ধারণা অন্তর্ভুক্ত রয়েছে ... অবশ্যই আরও বেশি অগ্রগতি দরকার :-)
ফায়ার

1

আপনার সহকর্মী কোথা থেকে তাদের প্যাটার্ন পেয়েছে তা উল্লেখ করা উচিত বলে আমি মনে করি।

আজকাল, সি # এর ট্রিগেট প্যাটার্ন রয়েছে public bool TryThing(out result)। ফলাফলটি যদি একটি কার্যকর মান হয় তবে এটি আপনাকে আপনার ফলাফল পেতে দেয়। (উদাহরণস্বরূপ, সমস্ত intমানগুলি এর বৈধ ফলাফল Math.sum(int, int), তবে যদি মানটি উপচে পড়ে যায় তবে এই নির্দিষ্ট ফলাফলটি আবর্জনা হতে পারে)। এটি যদিও তুলনামূলকভাবে নতুন প্যাটার্ন।

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

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

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


মূলশব্দটির আগে out, আপনি এমন একটি boolফাংশন লিখবেন যা ফলাফলের দিকে নির্দেশ করবে, অর্থাত refপ্যারামিটার। আপনি 1998 সালে VB6 এ এটি করতে পারেন The outকীওয়ার্ডটি আপনাকে কেবলমাত্র কম্পাইল-টাইম সুনিশ্চিত ক্রয় করে যে ফাংশনটি ফিরে আসার পরে প্যারামিটারটি নির্ধারিত হয়, এটি এখানে রয়েছে। এটা তোলে হয় একটা চমৎকার ও দরকারী প্যাটার্ন যদিও।
ম্যাথিউ গুইন্ডন

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

0

এমন সময় আছে যখন আপনি তাঁর পদ্ধতিটি করতে চান, তবে আমি তাদেরকে "স্বাভাবিক" পরিস্থিতি হিসাবে বিবেচনা করব না। আপনি কোন মামলায় রয়েছেন তা নির্ধারণের মূলটি হ'ল:

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

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

ব্যর্থতার পরে আমি যে মূল প্রশ্নটি জিজ্ঞাসা করব তা হ'ল "সিস্টেমটি কি এমন একটি রাষ্ট্রের যেখানে ব্যবহারকারীদের প্রত্যাশা এবং সফ্টওয়্যারটির আক্রমণকারীরা বৈধ?" যদি তা হয় তবে তবে সমস্ত উপায়ে কেবল ফিরে আসুন এবং চালিয়ে যান। ব্যবহারিকভাবে বলতে গেলে এটি বেশিরভাগ প্রোগ্রামে ঘটে না।

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

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


0

এই নির্দিষ্ট উদাহরণটিতে একটি আকর্ষণীয় বৈশিষ্ট্য রয়েছে যা নিয়মকে প্রভাবিত করতে পারে ...

CalculateArea(int x, int y)
{
    if(x < 0 || y < 0)
    {
        if(shouldThrowExceptions) 
            throwException;
        else
            return 0;
    }
}

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

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

এটি বলেছিল, ব্যর্থ চেক পরিচালনার জন্য দুটি ভিন্ন কৌশল থাকার সাথে আমি মৌলিকভাবে কোনও ভুল দেখতে পাচ্ছি না। আমার পছন্দটি হ'ল কোন কৌশলটি ব্যবহার হচ্ছে তা নির্ধারণের জন্য রচনাটি ব্যবহার করা; বৈশিষ্ট্য পতাকাটি গ্রন্থাগার পদ্ধতি বাস্তবায়নের পরিবর্তে রচনার মূলটিতে ব্যবহৃত হবে।

// Configurable dependencies
AreaCalculator(PreconditionFailureStrategy strategy)

CalculateArea(int x, int y)
{
    if (x < 0 || y < 0) {
        return this.strategy.fail(0);
    }
    // ...
}

তারা বিমান চালনার বিষয়ে সমালোচনামূলক অ্যাপ্লিকেশনগুলিতে কাজ করেছে যেখানে সিস্টেমটি নামতে পারে না।

জাতীয় ট্র্যাফিক এবং সুরক্ষা বোর্ড সত্যই ভাল; আমি ধূসর কার্ডগুলিতে বিকল্প বাস্তবায়ন কৌশলগুলি প্রস্তাব করতে পারি, তবে ত্রুটি প্রতিবেদনকারী সাবসিস্টেমে বাল্কহেডগুলি ডিজাইন করার বিষয়ে আমি তাদের সাথে তর্ক করতে আগ্রহী নই।

আরও বিস্তৃতভাবে: ব্যবসায়ের জন্য ব্যয় কী? এটি একটি জীবন জটিল সিস্টেমের চেয়ে কোনও ওয়েবসাইট ক্রাশ করা অনেক সস্তা che


আমি আধুনিকীকরণের সময় পছন্দসই নমনীয়তা বজায় রাখার বিকল্প উপায়ের পরামর্শটি পছন্দ করি।
drjpizzle

-1

পদ্ধতিগুলি হয় ব্যতিক্রমগুলি পরিচালনা করে বা তারা তা করে না, সি # এর মতো ভাষায় ফ্ল্যাগের প্রয়োজন নেই।

public int Method1()
{
  ...code

 return 0;
}

যদি কিছু ... কোডে খারাপ হয়ে যায় তবে সেই ব্যতিক্রমটি কলকারী দ্বারা পরিচালনা করতে হবে। যদি কেউ ত্রুটিটি পরিচালনা না করে তবে প্রোগ্রামটি শেষ হবে।

public int Method1()
{
try {  
...code
}
catch {}
 ...Handle error 
}
return 0;
}

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

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


3
ওপি পোস্ট করা বর্তমান সেটআপটি স্বেচ্ছায় কোনও ব্যতিক্রম ছুঁড়ে ফেলবে কিনা তা সিদ্ধান্ত নিয়েছে। ওপির কোড মেমরির ব্যতিক্রমগুলির মতো জিনিসগুলিকে অযাচিত গ্রাস করতে পারে না। যদি কিছু হয় তবে, সিস্টেমটি ক্র্যাশ করে ব্যতিক্রমগুলি যুক্তি থেকে বোঝা যায় যে কোড বেসটি ব্যতিক্রমগুলি ধরে না এবং এইভাবে কোনও ব্যতিক্রম গ্রাস করবে না; ওপি'র ব্যবসায়িক যুক্তি দ্বারা ইচ্ছাকৃতভাবে এগুলি ছিল এবং ছুঁড়ে দেওয়া হয়নি both
ফ্ল্যাটার

-1

এই পদ্ধতির "ব্যর্থ দ্রুত, কঠিন ব্যর্থ" দর্শনকে ভেঙে দেয়।

আপনি কেন দ্রুত ব্যর্থ হতে চান :

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

দ্রুত এবং কঠোর ব্যর্থ না হওয়ার ত্রুটিগুলি :

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

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

সুতরাং, কেবলমাত্র সহজ প্রযুক্তিগত কারণগুলিই নয়, "সিস্টেম" কারণগুলিও এটি দ্রুত ব্যর্থ হওয়া খুব কার্যকর করে তোলে।

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

বিশেষ করে আপনার নির্দিষ্ট ক্ষেত্রে, যেখানে আপনি এমনকি কিনা ব্যতিক্রম বা না নিক্ষেপ করা সম্পর্কে একটি বিকল্প প্রদান মধ্যে: এর মানে আহ্বানকারী সিদ্ধান্ত নিতে যে কোন পথে । সুতরাং কলার ব্যতিক্রমটি ধরতে এবং যথাযথভাবে পরিচালনা করতে মোটেই কোনও ত্রুটি নেই।

একটি মন্তব্যে একটি বক্তব্য আসছে:

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

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

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


3
অন্যান্য উত্তরে এটি উল্লেখ করা হয়েছে যে আপনি যে হার্ডওয়ারটি চালাচ্ছেন বিমানটি যখন বিমান চালানো হয় তখন কোনও জটিল অ্যাপ্লিকেশনটিতে দ্রুত এবং হার্ড ব্যর্থ হওয়া বাঞ্ছনীয় নয়।
HAEM

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

অভিপ্রায়টি 'সেই কঠিন' ব্যর্থ না হওয়া সত্ত্বেও, এখনও সেই ধরণের আগুনের সাথে খেলে যাওয়া ঝুঁকিপূর্ণ হিসাবে দেখা যায়।
drjpizzle

এই জাতীয় বিন্দু, @ ড্রজপিজল। আপনি যদি হার্ড-ব্যর্থ দ্রুত ব্যর্থ হয়ে পড়েন তবে এটি আমার অভিজ্ঞতাতে "ঝুঁকিপূর্ণ" বা "এই ধরণের আগুনের সাথে খেলা" নয়। আউ বিপরীত। এর অর্থ আপনি "এখানে একটি ব্যতিক্রম পেলাম তবে কী হবে", যেখানে "এখানে" অর্থ সর্বত্র , এবং আপনি বর্তমানে যে স্থানে কর্মসূচী করছেন সেখানে যে কোনও সমস্যা রয়েছে কিনা তা নিয়ে আপনি সচেতন হওয়ার প্রবণতাটির অর্থ ( বিমান দুর্ঘটনা, যাই হোক না কেন সে ক্ষেত্রে)। আগুন নিয়ে খেললে প্রত্যাশা করা যে সবকিছু বেশিরভাগ ঠিক হয়ে যাচ্ছে, এবং প্রতিটি উপাদান সন্দেহজনকভাবে ভান করে যে সবকিছু ঠিক আছে ...
AnoE
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.