সম্ভবত অকেজো ব্যতিক্রম হ্যান্ডলিং সহ কোড শক্তিশালী করা


12

কোডের অন্য অংশটি সঠিকভাবে কোডড না করা ক্ষেত্রে অযথা ব্যতিক্রম হ্যান্ডলিং বাস্তবায়ন করা কি একটি ভাল অনুশীলন?

বেসিক উদাহরণ

একটি সাধারণ, তাই আমি সবাইকে ছেড়ে দেব না :)।

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

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

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

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

আরেকটি উদাহরণ

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

প্রস্নগুলা

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

সম্ভাব্য ক্রাশ প্রতিরোধের জন্য প্রয়োজনীয় যা করা উচিত তা করা উচিত, এমনকি যদি আমি খারাপ কেসটি হ্যান্ডেল করার কথা না হয় তবেও?

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

সাধারণভাবে, এই প্রশ্নটি অপ্রয়োজনীয় ব্যতিক্রম পরিচালনা পরিচালনা করে t আমি এটি জিজ্ঞাসা করছি কারণ যখন আমি কোনও প্রকল্পে একা কাজ করি, আমি ধারাবাহিক ফাংশনগুলিতে হ্যান্ডলিংয়ের অনুরূপ 2-3 বার কোড করতে পারি, "ঠিক যদি" ​​আমি কিছু ভুল করেছিলাম এবং একটি খারাপ কেস আসতে পারি।


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

1
হ্যাঁ, উপযুক্ত শব্দটি হল "ব্যতিক্রম হ্যান্ডলিং"।
rdurand

তখন ভুল ট্যাগটি পরিবর্তন হয়েছে
ডক ব্রাউন

আমি আপনাকে ডেইলিডব্লিউটিএফ - তে উল্লেখ করি - আপনি কি নিশ্চিত যে আপনি এই জাতীয় পরীক্ষা করতে চান?
gbjbaanb

@gbjbaanb: আমি যদি আপনার লিঙ্কটি সঠিকভাবে বুঝতে পারি তবে আমি যা বলছি তা মোটেই তা নয়। আমি "বোকা পরীক্ষা" সম্পর্কে বলছি না, আমি ব্যতিক্রম হ্যান্ডলিংয়ের নকল করার কথা বলছি।
rdurand

উত্তর:


14

আপনি এখানে যে বিষয়ে কথা বলছেন তা হ'ল বিশ্বাসের সীমানা । আপনি কি আপনার অ্যাপ্লিকেশন এবং ডাটাবেসের মধ্যে সীমানা বিশ্বাস করেন? ডাটাবেস বিশ্বাস করে যে অ্যাপ্লিকেশন থেকে ডেটা সর্বদা প্রাক-বৈধ হয়?

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


5

দৃust়তার নীতি "আপনি যা প্রেরণ করেন তাতে রক্ষণশীল হন, আপনি যা গ্রহণ করেন তাতে উদার হন" আপনি হলেন পরে। এটি একটি উত্তম নীতি - সম্পাদনা করুন: যতক্ষণ না এর প্রয়োগটি কোনও গুরুতর ত্রুটি গোপন করে না - তবে আমি @ পিডিআর এর সাথে একমত যে আপনি যদি এটি প্রয়োগ করেন বা না করেন তবে এটি সর্বদা পরিস্থিতির উপর নির্ভর করে।


কিছু লোক মনে করেন যে "দৃust়তা নীতি" বাজে কথা। নিবন্ধটি একটি উদাহরণ দেয়।

@ ম্যাটফেনউইক: এটি একটি বৈধ পয়েন্ট উল্লেখ করার জন্য ধন্যবাদ, আমি আমার উত্তরটি কিছুটা পরিবর্তন করেছি।
ডক ব্রাউন

2
এটি "আরও দৃ
ness

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

1
@ ডকব্রাউন: ঠিক এই কারণেই আপনি যা গ্রহণ করেন তাতে কখনও উদার হওয়া উচিত ছিল না। দৃust়তার অর্থ এই নয় যে আপনার কাছে নিক্ষেপ করা সমস্ত কিছু আপনাকে গ্রহণ করা দরকার, কেবল যে আপনাকে বিধ্বস্ত না করে আপনার দেওয়া সমস্ত জিনিস গ্রহণ করা দরকার।
মার্জন ভেনেমা

1

এটি আপনি যা পরীক্ষা করছেন তার উপর নির্ভর করে; তবে ধরা যাক আপনার পরীক্ষার সুযোগটি কেবলমাত্র আপনার নিজের কোড। সেক্ষেত্রে আপনার পরীক্ষা করা উচিত:

  • "হ্যাপি কেস": আপনার অ্যাপ্লিকেশনটির বৈধ ইনপুট খাওয়ান এবং এটি সঠিক আউটপুট উত্পাদন করে তা নিশ্চিত করুন।
  • ব্যর্থতার ক্ষেত্রে: আপনার অ্যাপ্লিকেশনটিকে অবৈধ ইনপুটগুলি খাওয়ান এবং নিশ্চিত করুন যে এটি সঠিকভাবে পরিচালনা করে।

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

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

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

function test_ValidUser() {
    // set up mocking and fixtures
    userid = 23;
    db = new MockDB();
    db.fixedResult = { firstName: "John", lastName: "Doe" };
    db.expectedCall = { method: 'getUser', params: { userid: userid } };
    userController = new UserController(db);
    expectedResult = "John Doe";

    // run the actual test
    actualResult = userController.displayUserAsString(userid);

    // check assertions
    assertEquals(expectedResult, actualResult);
    db.assertExpectedCall();
}

এবং এখানে সঠিক প্রতিবেদন করা ক্ষেত্রগুলির জন্য আপনি কীভাবে পরীক্ষা করতে চান তা এখানে :

function test_IncompleteUser() {
    // set up mocking and fixtures
    userid = 57;
    db = new MockDB();
    db.fixedResult = { firstName: "John", lastName: "NA" };
    db.expectedCall = { method: 'getUser', params: { userid: userid } };
    userController = new UserController(db);

    // let's say the user controller is specified to leave "NA" fields 
    // blank
    expectedResult = "John";

    // run the actual test
    actualResult = userController.displayUserAsString(userid);

    // check assertions
    assertEquals(expectedResult, actualResult);
    db.assertExpectedCall();
}

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

class MockDB {
    // ... snip
    function getUser(userid) {
        if (this.fixedException) {
            throw this.fixedException;
        }
        else {
            return this.fixedResult;
        }
    }
}

এবং তারপরে আমাদের পরীক্ষার কেসটি এমন দেখাচ্ছে:

function test_MisbehavingUser() {
    // set up mocking and fixtures
    userid = 57;
    db = new MockDB();
    db.fixedException = new SQLException("You have an error in your SQL syntax");
    db.expectedCall = { method: 'getUser', params: { userid: userid } };
    userController = new UserController(db);

    // run the actual test
    try {
        userController.displayUserAsString(userid);
    }
    catch (DatabaseException ex) {
        // This is good: our userController has caught the raw exception
        // from the database layer and wrapped it in a DatabaseException.
        return TEST_PASSED;
    }
    catch (Exception ex) {
        // This is not good: we have an exception, but it's the wrong kind.
        testLog.log("Found the wrong exception: " + ex);
        return TEST_FAILED;
    }
    // This is bad, too: either our mocking class didn't throw even when it
    // should have, or our userController swallowed the exception and
    // discarded it
    testLog.log("Expected an exception to be thrown, but nothing happened.");
    return TEST_FAILED;
}

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

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


আপনি প্রশ্নের নীচে মন্তব্য পড়েন? ওপি "পরীক্ষা" লিখেছিল, তবে তার অর্থ এটি "বৈধতা যাচাই" এবং / বা "ব্যতিক্রম হ্যান্ডলিং" অর্থে ছিল
ডক ব্রাউন

1
@ টেডামার্স: ভুল বোঝাবুঝির জন্য দুঃখিত, আমি আসলে ব্যতিক্রম হ্যান্ডলিংয়ের অর্থ দিয়েছিলাম .. যাইহোক সম্পূর্ণ উত্তরের জন্য ধন্যবাদ, শেষ অনুচ্ছেদটি আমি যা খুঁজছিলাম।
rdurand

1

আমি কোড করার চেষ্টা করি এমন 3 টি মূল নীতি রয়েছে:

  • শুকনো

  • চুম্বন

  • YAGNI

এই সমস্তটি বন্ধ করে দেওয়া হ'ল আপনি বৈধতা কোডটি লেখার ঝুঁকি নিয়েছেন যা অন্য কোথাও সদৃশ is যদি বৈধতার বিধি পরিবর্তন হয় তবে এগুলি একাধিক স্থানে আপডেট করা দরকার।

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

যে কোনও অতিরিক্ত কোড (যদিও তা কখনই পরিবর্তন হয় না) ওভারহেড হয় কারণ এটি লিখতে, পড়তে, সঞ্চিত করতে এবং পরীক্ষার প্রয়োজন হবে।

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


1

সাধারণ মানুষের কথায়।

"ডাটাবেস" বা "অ্যাপ্লিকেশন" বলে কোনও জিনিস নেই ।

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

আবার

  • ডাটাবেস-> ত্রুটি ফেলে দিন
  • বিজনেস লজিক-> ত্রুটিগুলি ধরা এবং ব্যতিক্রম ছোঁড়া
  • উপস্থাপনা স্তর-> বৈধতা দিন, ব্যতিক্রম নিক্ষেপ করুন বা দু: খিত বার্তা দেখান।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.