একটি ব্যতিক্রম পুনর্বিবেচনা কি একটি বিমূর্ততা ফাঁস?

Question

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

// in the interface

/**
 * @return This method returns a doohickey to use when you need to foo
 * @throws DoohickeyDisasterException
 */
public function getThatDoohickey();

// in the implementation

public function getThatDoohickey() {

    try {
        $SomethingInTheClass->doSomethingThatThrowsAnException();
    } catch (Exception $Exc) {
        throw new DoohickeyDisasterException('Message about doohickey failure');
    }

    // other code may return the doohickey

}

আমি বিমূর্ততা ফাঁস হওয়া থেকে রোধ করার প্রয়াসে এই পদ্ধতিটি ব্যবহার করছি।

আমার প্রশ্নগুলি হল: পূর্ববর্তী ব্যতিক্রম হিসাবে নিক্ষিপ্ত অভ্যন্তরীণ ব্যতিক্রমটি কী বিমূর্ততা ফাঁস হবে? যদি তা না হয় তবে কেবল পূর্ববর্তী ব্যতিক্রমের বার্তাটি পুনরায় ব্যবহার করা কি উপযুক্ত হবে? যদি এটি বিমূর্ততা ফাঁস হয়ে যায় তবে আপনি কেন মনে করেন যে এটি কেন করে সে সম্পর্কে কোনও গাইডলাইন সরবরাহ করতে পারেন?

কেবল পরিষ্কার করার জন্য, আমার প্রশ্নে নিম্নলিখিত কোডের লাইনে পরিবর্তন জড়িত

throw new DoohickeyDisasterException($Exc->getMessage(), null, $Exc);

Comments

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

— মাকিং হাঁস

Answer 1

আমার প্রশ্নগুলি হল: পূর্ববর্তী ব্যতিক্রম হিসাবে নিক্ষিপ্ত অভ্যন্তরীণ ব্যতিক্রমটি কী বিমূর্ততা ফাঁস হবে? যদি তা না হয় তবে কেবল পূর্ববর্তী ব্যতিক্রমের বার্তাটি পুনরায় ব্যবহার করা কি উপযুক্ত হবে?

উত্তরটি হল, এটা নির্ভরশীল".

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

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

যদিও প্রায়শই কেবল ব্যতিক্রমটিকে মঞ্জুরি দেওয়া বাস্তবায়নের খুব যুক্তিসঙ্গত পছন্দ এবং বিমূর্ততার সমস্যা নয়। কেবল জিজ্ঞাসা করুন "আমি যে কোডটি কল করছি তা যদি না করত তবে আমি কি এটি ফেলে দেব?"

Answer 2

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

কিন্তু।

বেশ কয়েক গুরুত্বপূর্ণ আর্গুমেন্ট তৈরি করা যেতে পারে বিরুদ্ধে করেছেন। এর মধ্যে উল্লেখযোগ্য হল:

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

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

Answer 3

প্রথমত, আপনি এখানে যা করছেন তা কোনও ব্যতিক্রম পুনর্বিবেচনা করছে না। পুনরুত্থন হ'ল আক্ষরিকভাবে এই একই ব্যতিক্রম ছুঁড়ে ফেলা হবে:

try {
    $SomethingInTheClass->doSomethingThatThrowsAnException();
} catch (Exception $Exc) {
    throw $Exc;
}

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

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

তবে এটি ফাঁসী বিমূর্ততা সম্পর্কে নয়, এটি অন্য একটি বিষয়।

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

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

try {
    $wrapper->getThatDoohickey();
} catch (DoohickeyDisasterException $Exc) {
    echo "The Doohickey is all wrong!";
    echo $Exc->getMessage();
    gotoAHappyPlaceAndSingHappySongs();
}

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

অন্যদিকে, যদি ডুিকিকিডিসাস্টার এক্সসেপশনটি আপনার নিজের তৈরি একটি হয় তবে আপনি বিমূর্ততা ফাঁস করছেন না, আমার প্রথম বিষয়টির সাথে আপনার নিজেকে আরও উদ্বেগ করা উচিত।

Answer 4

আমি যে নিয়মটি অনুসরণ করার চেষ্টা করছি তা হ'ল: যদি আপনি এটি তৈরি করেন তবে এটি মোড়ানো। একইভাবে, রানটাইম ব্যতিক্রমের কারণে যদি কোনও বাগ তৈরি করা হয় তবে এটি কোনও প্রকারের DoHickeyException বা MyApplicationException হওয়া উচিত।

এর দ্বারা বোঝা যায় যে ত্রুটির কারণটি যদি আপনার কোডের বাহ্যিক কিছু হয় এবং আপনি এটির ব্যর্থতা আশা করেন না তবে নিখুঁতভাবে ব্যর্থ হন এবং এটিকে পুনরায় প্রবর্তন করুন। তেমনি, যদি এটি আপনার কোড নিয়ে কোনও সমস্যা হয় তবে এটি (সম্ভাব্য) কাস্টম ব্যতিক্রমতে মুড়ে দিন।

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