ব্যতিক্রম নিক্ষেপ করুন বা কোড ব্যর্থ হোক


52

আমি ভাবছি এই শৈলীর বিপরীতে কোনও মতামত আছে কিনা:

private void LoadMaterial(string name)
{
    if (_Materials.ContainsKey(name))
    {
        throw new ArgumentException("The material named " + name + " has already been loaded.");
    }

    _Materials.Add(
        name,
        Resources.Load(string.Format("Materials/{0}", name)) as Material
    );
}

এই পদ্ধতিটি, প্রত্যেকের জন্য name, একবারে একবার চালানো উচিত । _Materials.Add()যদি এটির জন্য একাধিকবার বলা হয় তবে এটি একটি ব্যতিক্রম ছুঁড়ে ফেলবে name। আমার প্রহরী, ফলস্বরূপ, সম্পূর্ণ অপ্রয়োজনীয়, বা কিছু কম সুস্পষ্ট সুবিধা আছে?

এটি সি #, ityক্য, যদি কেউ আগ্রহী হয়।


3
আপনি যদি কোনও প্রহরী ছাড়া দু'বার কোনও উপাদান লোড করেন তবে কী হবে? না _Materials.Addএকটি ব্যতিক্রম নিক্ষেপ?
ব্যবহারকারী 253751

2
আসলে আমি ইতিমধ্যে একটি ব্যতিক্রম ছোঁড়ে উল্লেখ করেছি: পি
async

9
পার্শ্ব নোট: 1) string.Formatব্যতিক্রম বার্তাটি তৈরি করার জন্য ওভার স্ট্রিং কনটেনটেশন ব্যবহার বিবেচনা করুন। 2) শুধুমাত্র ব্যবহার asযদি আপনি ব্যর্থ এবং জন্য ফলাফল পরীক্ষা করার জন্য ঢালাই আশা null। আপনি যদি সর্বদা একটি পাওয়ার প্রত্যাশা করেন তবে Materialকাস্ট ব্যবহার করুন (Material)Resources.Load(...)। একটি স্পষ্ট কাস্ট ব্যতিক্রম নাল রেফারেন্স ব্যতিক্রমের পরে ডিবাগ করা সহজ is
কোডসইনচওস

3
এই নির্দিষ্ট ক্ষেত্রে, আপনার কলকারীরা কোনও সঙ্গী LoadMaterialIfNotLoadedবা ReloadMaterial(এই নামটি উন্নতি করতে পারে) পদ্ধতিটিও দরকারী খুঁজে পেতে পারে।
jpmc26

1
অন্য নোটে: এই প্যাটার্নটি কখনও কখনও তালিকায় কোনও আইটেম যুক্ত করার জন্য ঠিক। তবে একটি সম্পূর্ণ তালিকা পূরণের জন্য এই প্যাটার্নটি ব্যবহার করবেন না কারণ আপনি একটি O (n ^ 2) পরিস্থিতিতে চলে যাবেন যেখানে বড় তালিকাগুলি সহ আপনি কার্য সম্পাদনের সমস্যাগুলিতে চলে আসবেন। আপনি এটি 100 এন্ট্রিগুলিতে লক্ষ্য করবেন না তবে 1000 এন্ট্রি আপনাকে অবশ্যই এবং 10.000 এন্ট্রি এ এটি একটি প্রধান বাধা হয়ে দাঁড়াবে।
পিটার বি

উত্তর:


109

উপকারটি হ'ল আপনার "কাস্টম" ব্যতিক্রমটিতে একটি ত্রুটি বার্তা রয়েছে যা এটি কীভাবে কার্যকর করা হয়েছে (যা ভবিষ্যতে আপনি হতে পারেন!) এটি না জেনে এই ফাংশনটি কল করার জন্য অর্থপূর্ণ ।

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


3
একমত। পূর্ব শর্ত লঙ্ঘনের জন্য ব্যতিক্রম ছুঁড়ে ফেলা প্রায় সর্বদা ভাল।
ফ্র্যাঙ্ক হিলিমান

22
"সুবিধাটি হ'ল আপনার" কাস্টম "ব্যতিক্রমটিতে একটি ত্রুটি বার্তা রয়েছে যা এই ফাংশনটি কল করে কীভাবে এটি কার্যকর করা হয়েছে তা জেনে না এসে (যা ভবিষ্যতে আপনি হতে পারেন!)! শীর্ষ পরামর্শ।
async

2
"স্পষ্ট বর্ণিত চেয়ে ভাল।" - পাইথনের জেন
jpmc26

4
তবুও ত্রুটিটি যদি _Materials.Addআপনি কলারের কাছে প্রেরণ করতে চান এমন ত্রুটি নাও হয় তবে আমি মনে করি ত্রুটিটি সম্পর্কিত এই পদ্ধতিটি অক্ষম। (স্বাভাবিক অপারেশন) এর প্রতিটি সফল কলের জন্য LoadMaterialআপনি একই বিচক্ষণতা পরীক্ষা দুটিবার করেছেন , LoadMaterialআবার এবং পরে আবার _Materials.Add। যদি আরও স্তর আবৃত হয়, প্রতিটি একই শৈলী নিযুক্ত করে, আপনি এমনকি আরও অনেকবার একই পরীক্ষায় থাকতে পারেন।
মার্ক ভ্যান লিউউইন

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

100

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

যদি সত্যিই প্রোগ্রামার ভুল হয় তবে একটি ব্যতিক্রম ছুঁড়ে দেওয়া ভাল fe


2
অন্যদিকে, কোনও ক্রিয়াকলাপটি নিঃশব্দে ব্যর্থ হওয়া অপ্রত্যাশিত আচরণের ফলে পরবর্তী সময়ে বাগগুলি খুঁজে পাওয়া শক্ত হতে পারে।
ফিলিপ

30
@ ফিলিপিস ফাংশনটি নিঃশব্দে ব্যর্থ হবে না। আদর্শবান হওয়ার অর্থ এটি হ'ল বহুবার চালানো একইভাবে একবার চালানোর মতো প্রভাব ফেলে। অন্য কথায়, যদি উপাদান ইতিমধ্যে লোড করা থাকে, তবে আমাদের অনুমান ("উপাদানটি বোঝা উচিত") ইতিমধ্যে সন্তুষ্ট, সুতরাং আমাদের কিছু করার দরকার নেই। আমরা কেবল ফিরে আসতে পারি।
ওয়ার্বো

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

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

7
আমি এই ধারণাটি পছন্দ করি তবে একটি ছোটখাট পরিবর্তন প্রস্তাব করি: কোনও কিছু বোঝা হয়েছিল কিনা তা প্রতিবিম্বিত করে একটি বুলিয়ান ফিরিয়ে দিন। যদি কলার সত্যই অ্যাপ্লিকেশন যুক্তির বিষয়ে চিন্তা করে তবে তারা এটি পরীক্ষা করে একটি ব্যতিক্রম ছুঁড়ে ফেলতে পারে।
user949300

8

আপনার যে মূল প্রশ্নটি জিজ্ঞাসা করতে হবে তা হ'ল: আপনার ফাংশনের ইন্টারফেসটি কী হতে চান? বিশেষত, শর্তটি _Materials.ContainsKey(name)কি ফাংশনের পূর্বশর্ত?

যদি এটি পূর্ব শর্ত না হয় তবে ফাংশনটি অবশ্যই সমস্ত সম্ভাব্য ভেলের জন্য একটি সু-সংজ্ঞায়িত ফলাফল সরবরাহ করতে হবেname । এই ক্ষেত্রে, nameঅংশ না থাকলে নিক্ষিপ্ত ব্যতিক্রমটি _Materialsফাংশনটির ইন্টারফেসের অংশ হয়ে যায়। এর অর্থ এটি ইন্টারফেস ডকুমেন্টেশনের অংশ হওয়া দরকার এবং যদি আপনি ভবিষ্যতে কখনও কখনও এই ব্যতিক্রমটি পরিবর্তন করার সিদ্ধান্ত নেন তবে সেটি হবে একটি ব্রেকিং ইন্টারফেস পরিবর্তন

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

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

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

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

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

ক্লাসিক প্রতিরক্ষামূলক পদ্ধতির সমস্যাগুলির বিশদ ব্যাখ্যার পাশাপাশি দৃsert়-শৈলীর পূর্বশর্ত চেকগুলির সম্ভাব্য প্রয়োগের জন্য জন লাকোসের টক ডিফেন্সিভ প্রোগ্রামিং সম্পন্ন হয়েছে সরাসরি সিপিপিসন 2014 ( স্লাইড , ভিডিও ) দেখুন।


4

এখানে ইতিমধ্যে কয়েকটি উত্তর রয়েছে, তবে এখানে দেওয়া উত্তর যা ইউনিটি 3 ডি অ্যাকাউন্টে নেয় (উত্তরটি ইউনিটি 3 ডি-তে খুব নির্দিষ্ট, আমি বেশিরভাগ প্রসঙ্গেই এর বেশিরভাগ ক্ষেত্রেই করব):

সাধারণভাবে, ইউনিটি 3 ডি ব্যতিক্রমগুলি traditionতিহ্যগতভাবে ব্যবহার করে না। আপনি যদি ইউনিটি 3 ডি-তে কোনও ব্যতিক্রম ছুঁড়ে ফেলে থাকেন তবে এটি আপনার গড় .NET অ্যাপ্লিকেশনের মতো কিছুই নয়, এটি প্রোগ্রামটি থামায় না, বেশিরভাগই আপনি সম্পাদককে বিরতি দেওয়ার জন্য কনফিগার করতে পারবেন না। এটি সবেমাত্র লগইন হবে। এটি সহজেই গেমটিকে একটি অবৈধ অবস্থায় ফেলতে পারে এবং একটি ক্যাসকেড প্রভাব তৈরি করতে পারে যা ত্রুটিগুলি ট্র্যাক করতে অসুবিধে করে। সুতরাং আমি ityক্যের ক্ষেত্রে বলব, Addএকটি ব্যতিক্রম ছুঁড়তে দেওয়া একটি বিশেষভাবে অনাকাঙ্ক্ষিত বিকল্প।

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

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

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

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

    public void Awake()
    {
        _inputParameters = GetComponent<VehicleInputParameters>();
        _rigidbody = GetComponent<Rigidbody>();
        _rigidbodyTransform = _rigidbody.transform;
        _raycastStrategySelector = GetComponent<RaycastStrategySelectionBehavior>();

        _trackParameters =
            SceneManager.InstanceOf.CurrentSceneData.GetValue<TrackParameters>();

        this.DisableIfNull(() => _rigidbody);
        this.DisableIfNull(() => _raycastStrategySelector);
        this.DisableIfNull(() => _inputParameters);
        this.DisableIfNull(() => _trackParameters);
    }

SceneData.GetValue<>আপনার উদাহরণের অনুরূপ এটি একটি অভিধানে একটি ফাংশনকে কল করে যা একটি ব্যতিক্রম ছুঁড়ে। তবে এটি কোনও ব্যতিক্রম ছুঁড়ে ফেলার পরিবর্তে এটি ব্যবহার করে Debug.LogErrorযা একটি সাধারণ ব্যতিক্রমের মতো স্ট্যাক ট্রেস দেয় এবং নাল ফেরায়। * অনুসরণ করে এমন চেকগুলি অবৈধ অবস্থায় থাকা চালিয়ে যাওয়ার পরিবর্তে আচরণটি অক্ষম করবে।

* চেকগুলি দেখতে এমন কোনও ছোট সহায়তার কারণে আমি সেই গেমের অবজেক্ট অক্ষম করে যখন একটি ফর্ম্যাট বার্তা প্রিন্ট করে ব্যবহার করি **। ifএখানে কাজের সাথে সরল নাল চেকগুলি (** সহায়তার চেকগুলি কেবলমাত্র ডিবাগ বিল্ডগুলিতে সংকলিত রয়েছে)


1
গাদা কিছু সত্যিকারের নতুন তথ্য যুক্ত করার জন্য +1। আমি এটা আশা করছিলাম না।
Ixrec

3

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

তেমনি, আপনার লোডমেটেরিয়ালের নাম পরিবর্তন করা উচিত লোডআইএফএবসেন্ট বা পুট বা ট্রাইলোড বা লোডঅরথ্রো (আপনি উত্তর # 1 বা # 2 ব্যবহার করেন কিনা তার উপর নির্ভর করে) বা এরকম কিছু।

সি # ইউনিটির নামকরণের কনভেনশনগুলি যা যা তা অনুসরণ করুন।

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


পার্থক্য রয়েছে বেটউইন সি # ডিকশনারি.সামেন্টিকস যুক্ত করুন ( এমএসডিএন.মাইক্রোসফটকম /en-us/library/k7z0zy8k%28v=vs.110%29.aspx ) এবং জাভা কালেকশন.এডিডি () শব্দার্থবিজ্ঞান ( দস্তাবেজ দেখুন) । oracle.com/javase/8/docs/api/java/util/… )। সি # অকার্যকর দেয় এবং ব্যতিক্রম ছোঁড়ে। অন্যদিকে, জাভা পুনরায় ফিরে আসে এবং পূর্বে সঞ্চিত মানটিকে নতুন মানের সাথে প্রতিস্থাপন করে বা নতুন উপাদান যুক্ত করা না গেলে একটি ব্যতিক্রম ছুঁড়ে দেয়।
ক্যাস্পার ভ্যান ডেন বার্গ

ক্যাস্পার - ধন্যবাদ, এবং আকর্ষণীয়। আপনি কীভাবে সি # অভিধানে একটি মান প্রতিস্থাপন করবেন? (একটি জাভা পুটের সমান) ()। এই পৃষ্ঠায় একটি অন্তর্নির্মিত পদ্ধতি দেখতে পাবেন না।
user949300

ভাল প্রশ্ন, কেউ ডিকশনারি করতে পারে। সরান () (দেখুন msdn.microsoft.com/en-us/library/bb356469%28v=vs.110%29.aspx ) এর পরে একটি অভিধান রয়েছে।এড করুন () দেখুন এমএসডিএন.মাইক্রোসফ্ট .কম / এন-ইউএস / লাইব্রেরি / বিবি 338565% 28 ভি = বনাম 1110% 29.aspx ), তবে এটি কিছুটা বিশ্রী প্রদর্শিত হবে।
ক্যাস্পার ভ্যান ডেন বার্গ

@ user949300 অভিধান [Key] = মান এন্ট্রি প্রতিস্থাপন যদি এটা আগে থেকেই আছে
Rupe

@ রুপি এবং সম্ভবত কিছু না ছুড়ে দিলে। সব আমার কাছে খুব বিশ্রী মনে হচ্ছে। সর্বাধিক অভি স্থাপনের ক্লায়েন্ট পরোয়া করি না wheteher একটি এন্ট্রি ছিল সেখানে, তারা শুধু পরোয়া করে, তাদের সেটআপ কোড পর হয় না। জাভা সংগ্রহগুলি API (IMHO) এর জন্য একটি স্কোর করুন। পিএইচপি এছাড়াও ডিক্টস সঙ্গে বিশ্রী, এটি একটি ভুল fot সি # যে নজির অনুসরণ করা ছিল।
user949300

3

সমস্ত উত্তর মূল্যবান ধারণা যুক্ত করে, আমি তাদের একত্রিত করতে চাই:

LoadMaterial()অপারেশনের উদ্দেশ্যে এবং প্রত্যাশিত শব্দার্থবিজ্ঞানের বিষয়ে সিদ্ধান্ত নিন । কমপক্ষে নিম্নলিখিত বিকল্পগুলি উপস্থিত রয়েছে:

  • nameলোডডমেটারিয়ালস : on এ পূর্ব শর্ত →

    যখন পূর্বশর্ত লঙ্ঘন করা হয়, প্রভাব LoadMaterial()অনির্দিষ্ট (হিসাবে উত্তর দ্বারা ComicSansMS )। এটি বাস্তবায়ন এবং ভবিষ্যতের পরিবর্তনগুলিতে সর্বাধিক স্বাধীনতার অনুমতি দেয় LoadMaterial()। অথবা,

  • কলিং প্রভাব LoadMaterial(name)সঙ্গে nameLoadedMaterials নিদিষ্ট করা হয়; করুন:

    • স্পেসিফিকেশন বলে যে একটি ব্যতিক্রম নিক্ষেপ করা হয়; অথবা
    • স্পেসিফিকেশন যে ফলাফল (হিসাবে idempotent হয় উত্তর দ্বারা কার্ল Bielefeldt ,)

শব্দার্থবিজ্ঞানের বিষয়ে সিদ্ধান্ত নেওয়ার পরে, আপনাকে অবশ্যই একটি বাস্তবায়ন বেছে নিতে হবে। নিম্নলিখিত বিকল্প এবং বিবেচনা যেখানে প্রস্তাবিত:

  • (যেমন একটি কাস্টম ব্যতিক্রম নিক্ষেপ প্রস্তাব দ্বারা Ixrec ) →

    উপকারটি হ'ল আপনার "কাস্টম" ব্যতিক্রমটিতে একটি ত্রুটি বার্তা রয়েছে যা এই ফাংশনটি কল করার জন্য অর্থপূর্ণ - Ixrec এবং ব্যবহারকারী16547

    • বারবার যাচাই করার ব্যয়টি এড়াতে nameলোডডমেটারিয়ালস আপনি মার্ক ভ্যান লিউউয়ের পরামর্শ অনুসরণ করতে পারেন :

      ... পরিবর্তে _যন্ত্রগুলিতে ডুবে যাওয়া বিবেচনা করুন unc শর্তহীন যুক্ত করুন, তারপরে একটি সম্ভাব্য ত্রুটি ধরুন এবং হ্যান্ডলারে অন্যটি নিক্ষেপ করুন।

  • যাক Dictionay.Add ব্যতিক্রম নিক্ষেপ →

    ব্যতিক্রম নিক্ষেপ করা কোডটি নিরর্থক। - জন রায়নার

    যদিও, বেশিরভাগ ভোটার Ixrec এর সাথে আরও সম্মত হন

    এই বাস্তবায়নটি বেছে নেওয়ার অতিরিক্ত কারণ হ'ল:

    • কলাররা ইতিমধ্যে ArgumentExceptionব্যতিক্রমগুলি পরিচালনা করতে পারে এবং
    • স্ট্যাকের তথ্য হারাতে এড়াতে।

    তবে যদি এই দুটি কারণ গুরুত্বপূর্ণ হয় তবে আপনি নিজের কাস্টম ব্যতিক্রম থেকেও এটিকে গ্রহণ করতে পারেন এবং মূলটিকে ArgumentExceptionশিকলযুক্ত ব্যতিক্রম হিসাবে ব্যবহার করতে পারেন।

  • কার্ল বিলেফেল্ট দ্বারা অ্যাঞ্জারLoadMaterial() হিসাবে আদর্শশক্তিকে তৈরি করুন এবং প্রায়শই (75 বার) আপগ্রেটেড হন ।

    এই আচরণের জন্য বাস্তবায়ন বিকল্পগুলি:

    • অভিধানের সাহায্যে পরীক্ষা করুন ont কন্টেইনকি ()

    • সর্বদা কল Dictionary.Add () ধরা ArgumentExceptionএটা ছোঁড়ার যখন চাবি আগে থেকেই আছে ঢুকিয়ে যে ব্যতিক্রম উপেক্ষা করার। নথিটি যা ব্যতিক্রম উপেক্ষা করে তা হল আপনি কী করতে চান এবং কেন।

      • যখন LoadMaterials()(প্রায়) সর্বদা প্রত্যেকের জন্য একবার ডাকা হয় name, এটি বারবার চেক করতে ব্যয় এড়ানো হয় nameলোডডমেটারিয়ালস সিএফ. মার্ক ভ্যান লিউউয়েন । যাহোক,
      • যখন LoadedMaterials()প্রায়শই nameএটির জন্য একাধিক বার বলা হয় , এটি নিক্ষেপকারী ArgumentExceptionএবং স্ট্যাকটি নিক্ষেপ করার ব্যয়বহুল (ব্যয়বহুল) হয় ।
    • আমি ভেবেছিলাম যে ট্রাইগেট () -এর একটি TryAddআদর্শগত অ্যানালগ রয়েছে যা আপনাকে ব্যয়বহুল ব্যতিক্রম নিক্ষেপ করতে এবং অভিধানে অকার্যকর কলগুলিকে স্ট্যান্ড না করে এড়াতে পারত dএড

      তবে এই TryAddআদর্শের অস্তিত্ব নেই বলে মনে হয়।


1
সর্বাধিক ব্যাপক উত্তর হওয়ার জন্য +1। এটি সম্ভবত ওপিটি মূলত যা ছিল তার চেয়ে অনেক বেশি এগিয়ে যায় তবে এটি সমস্ত বিকল্পের একটি দরকারী সংক্ষিপ্তসার।
Ixrec

1

ব্যতিক্রম নিক্ষেপ করা কোডটি নিরর্থক।

যদি আপনি কল করেন:

_মাটিরিয়ালস.একটি উপাদান হিসাবে (নাম, রিসোর্সস.লড (স্ট্রিং.ফর্ম্যাট ("উপকরণ / {0}", নাম)) যুক্ত করুন

একই কী দিয়ে এটি নিক্ষেপ করবে

System.ArgumentException

বার্তাটি হবে: "একই কী সহ একটি আইটেম ইতিমধ্যে যুক্ত করা হয়েছে।"

ContainsKeyচেক অপ্রয়োজনীয় যেহেতু মূলত একই আচরণ এটাকে ছাড়া অর্জন করা হয়। একমাত্র যে আইটেমটি আলাদা তা ব্যতিক্রমের আসল বার্তা। যদি কাস্টম ত্রুটি বার্তাটি দিয়ে সত্যিকারের সুবিধা থাকে তবে গার্ড কোডটিতে কিছু যোগ্যতা থাকে।

অন্যথায়, আমি সম্ভবত এক্ষেত্রে প্রহরীটিকে বের করে দেব।


0

আমি মনে করি কোডিং কনভেনশন প্রশ্নের চেয়ে এটি API নকশা সম্পর্কে আরও প্রশ্ন more

কল করার প্রত্যাশিত ফলাফল (চুক্তি) কী:

LoadMaterial("wood");

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

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


-2

পদ্ধতিটি কেন পরিবর্তন করবেন না কেন এটি 'সত্য' ফিরে আসে কেননা এটি মেটেরিয়াল যুক্ত হয় এবং 'মিথ্যা' যদি তা না থাকে?

private bool LoadMaterial(string name)
{
   if (_Materials.ContainsKey(name))

    {

        return false; //already present
    }

    _Materials.Add(
        name,
        Resources.Load(string.Format("Materials/{0}", name)) as Material
    );

    return true;

}

15
যে ক্রিয়াকলাপগুলি ত্রুটির মানগুলি ফিরিয়ে দেয় তা হ'ল ব্যতীত প্যাটার্ন যা ব্যতিক্রমগুলি অপ্রচলিত বলে মনে করা হয়।
ফিলিপ

এই সবসময় ক্ষেত্রে? আমি ভেবেছিলাম এটা শুধুমাত্র semipredicate (সঙ্গে কেস ছিল en.wikipedia.org/wiki/Semipredicate_problem কারণ ওপি কোড নমুনা), যোগ করার জন্য সিস্টেমের জন্য একটি উপাদান কোনো সত্যিকারের সমস্যা ব্যর্থ। আপনি যখন এটি চালাবেন তখন উপাদানটি সিস্টেমে রয়েছে কিনা তা নিশ্চিত করার পদ্ধতিটি এর উদ্দেশ্য এবং এটি এই পদ্ধতিটি ঠিক তাই করে। (এমনকি এটি ব্যর্থ হলেও) রিটার্নিং বুলিয়ানটি কেবল ইঙ্গিত করে যে পদ্ধতিটি ইতিমধ্যে এই ম্যাট্রোলিয়াল যুক্ত করার চেষ্টা করেছে কিনা। PS: আমি একথা বিবেচনা করি না যে একই নামের সাথে একাধিক মেটেরিয়াল থাকতে পারে।
মিঃআইভেক

1
আমি সমাধান নিজেকে খুঁজে পাওয়া যায়: en.wikipedia.org/wiki/... এই যে পয়েন্ট আউট Ixrec এর উত্তর সবচেয়ে সঠিক
MrIveck

@ ফিলিপিস ক্ষেত্রে কোডার / স্পেক সিদ্ধান্ত নিয়েছে যে আপনি যখন দুবার লোড করার চেষ্টা করবেন তখন কোনও ত্রুটি নেই । রিটার্ন মান হ'ল সেই অর্থে ত্রুটি মান নয় তবে একটি তথ্যগত মান।
user949300
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.