আনহ্যান্ডেল ব্যতিক্রমগুলি কীভাবে আচরণ করবেন? (অ্যাপ্লিকেশনটি শেষ করুন বনাম এটিকে বাঁচিয়ে রাখুন)


30

একটি ডেস্কটপ অ্যাপ্লিকেশনটিতে যখন কোনও অপরিহার্য ব্যতিক্রম ঘটে তখন সেরা অনুশীলন কী?

আমি ব্যবহারকারীকে একটি বার্তা দেখানোর কথা ভাবছিলাম, যাতে সে সমর্থনে যোগাযোগ করতে পারে। আমি ব্যবহারকারীকে অ্যাপ্লিকেশনটি পুনরায় চালু করার পরামর্শ দিচ্ছি, তবে তা জোর করে না। এখানে যা আলোচনা করা হয় তার অনুরূপ: ux.stackexchange.com - অপ্রত্যাশিত অ্যাপ্লিকেশন ত্রুটিগুলি পরিচালনা করার সর্বোত্তম উপায় কোনটি?

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

public partial class App : Application
{
    public App()
    {
        DispatcherUnhandledException += OnDispatcherUnhandledException;
    }

    private void OnDispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
    {
        LogError(e.Exception);
        MessageBoxResult result = MessageBox.Show(
             $"Please help us fix it and contact support@example.com. Exception details: {e.Exception}" +
                        "We recommend to restart the application. " +
                        "Do you want to stop the application now? (Warning: Unsaved data gets lost).", 
            "Unexpected error occured.", MessageBoxButton.YesNo);

        // Setting 'Handled' to 'true' will prevent the application from terminating.
        e.Handled = result == MessageBoxResult.No;
    }

    private void LogError(Exception ex)
    {
        // Log to a log file...
    }
}

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

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

অথবা আপনি যে ধরনের অ্যাপ্লিকেশন লিখছেন তার উপর নির্ভর করে যদি আপনার হাতছাড়া ব্যতিক্রম নিয়ে অ্যাপ্লিকেশনটি সমাপ্ত করা উচিত তবে সিদ্ধান্তটি কি? কোড সম্পূর্ণ, দ্বিতীয় সংস্করণে বর্ণিত মত "দৃness়তা" বনাম "যথার্থতা" এর মধ্যে এটি কি কেবল বাণিজ্য?

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


27
আপনি যদি কোনও ব্যতিক্রম প্রত্যাশা না করেন তবে আপনি কীভাবে নিশ্চিত হন যে অ্যাপ্লিকেশনটি নিরাপদে প্লডডিং চালিয়ে যেতে পারে?
ed

2
@ প্রতিলিপি: অবশ্যই আপনি নিশ্চিত হতে পারবেন না ম্যাথিউয়ের উত্তরে মন্তব্য হিসাবে ইতিমধ্যে লেখা আছে : "হ্যাঁ, অবশ্যই অ্যাপ্লিকেশনটি একটি অবৈধ অবস্থায় থাকতে পারে Maybe সম্ভবত কিছু ভিউমোডেল কেবলমাত্র আংশিকভাবে আপডেট হয়েছে But তবে এটির কোনও ক্ষতি হতে পারে? ব্যবহারকারী ডেটা পুনরায় লোড করতে পারে এবং যদি কিছু অবৈধ হবে তবে পরিষেবাতে প্রেরণ করুন, তারপরেও পরিষেবাটি এটি কোনওভাবেই গ্রহণ করবে না user যদি অ্যাপ্লিকেশনটি পুনরায় চালু করার আগে সে যদি সেভ করতে সক্ষম হয় তবে ব্যবহারকারীর পক্ষে কি এটি ভাল নয়? "
জোনাস বেনজ

2
@ ভু সুতরাং, আপনি নিশ্চিত হন যে অ্যাপ্লিকেশনটি সর্বদা একটি ব্যতিক্রম আশা করে নিরাপদে চলতে পারে? মনে হচ্ছে আপনি একটি অপ্রত্যাশিত ব্যতিক্রম প্রাপ্তির ভিত্তিকে অস্বীকার করছেন।
Deduplicator

2
যে কোনও ক্ষেত্রে, দয়া করে ত্রুটি বার্তাটি অনুলিপি করুন। বিকল্পভাবে, কোন লগ ফাইলটিতে এটি লেখা হয়েছে তা বলুন।
কমফ্রিচ

2
হ্যান্ডলিং অগত্যা সুস্পষ্ট পদক্ষেপ বোঝায় না। আপনি যদি নিশ্চিত হন যে অ্যাপ্লিকেশনটি নিরাপদে চালিয়ে যেতে পারে তবে আপনি ব্যতিক্রমটি পরিচালনা করেছেন।
চিপনার

উত্তর:


47

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

নিম্নলিখিত বিষয়গুলি বিশ্লেষণ করে শুরু করুন:

  • একটি প্রোগ্রাম সমাপ্তির ক্ষেত্রে আসলে কতটা ডেটা হারিয়ে যেতে পারে?

  • ব্যবহারকারীর পক্ষে এমন ক্ষতি কতটা গুরুতর? হারানো ডেটা কি 5 মিনিটেরও কম সময়ে পুনর্গঠন করা যায়, বা আমরা কোনও দিনের কাজ হারাতে বলছি?

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

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

যদি এই জাতীয় "মধ্যবর্তী ব্যাকআপ" কৌশলটি বোধগম্য হয় তবে তা প্রয়োগ এবং তার আর্কিটেকচারের উপর এবং জড়িত ডেটার প্রকৃতি এবং কাঠামোর উপর নির্ভর করে। তবে যদি ব্যবহারকারী 10 মিনিটেরও কম কাজের কাজ শিথিল করেন এবং এই জাতীয় ক্রাশটি সপ্তাহে একবারে বা তার চেয়ে বেশি কদাচিৎ ঘটে থাকে তবে আমি সম্ভবত এটি নিয়ে খুব বেশি চিন্তাভাবনা করব না।


10
en.wikedia.org/wiki/Crash-only_software এবং অ্যানড্রয়েড অ্যাপ্লিকেশনগুলি প্রয়োজনীয়তার সাথে এইভাবে কাজ করে।
মাকিং হাঁস

3
দুর্দান্ত উত্তর - এবং বিস্তৃত প্রসঙ্গে জিনিসগুলি বিবেচনার জন্য একটি দুর্দান্ত উদাহরণ (এই ক্ষেত্রে "আমরা ক্র্যাশের কোনও ক্ষেত্রে কীভাবে ডেটা ক্ষতি রোধ করতে পারি?") আরও ভাল সমাধানের দিকে নিয়ে যায়।

1
আমি মনে করি একটি ছোট সম্পাদনা করেছি যে আপনার পুরানো ডেটা ওভাররাইট করা উচিত নয় - আশা করি আপনার আপত্তি নেই।

1
@ মুভিংডাক প্রচুর অ্যান্ড্রয়েড অ্যাপ্লিকেশন (যেমন গেমস) ক্র্যাশে তাদের রাজ্য হারাবে।
ব্যবহারকারী 253751

1
@ মিম্বিস: হ্যাঁ, অ্যান্ড্রয়েডের সত্যিকারের নিম্ন মানের অ্যাপ রয়েছে।
হাঁসকে

30

এটি আপনি যে অ্যাপ্লিকেশনটি বিকাশ করছেন তার উপর কিছুটা নির্ভর করে তবে সাধারণভাবে, আমি বলতে পারি যে যদি আপনার অ্যাপ্লিকেশনটি একটি নিয়ন্ত্রণহীন ব্যতিক্রমের মুখোমুখি হয় তবে আপনাকে এটি বন্ধ করতে হবে।

কেন?

কারণ আপনি আর আবেদনের স্থিতিতে কোনও আস্থা রাখতে পারবেন না।

অবশ্যই, ব্যবহারকারীকে একটি সহায়ক বার্তা সরবরাহ করুন, তবে আপনার শেষ পর্যন্ত অ্যাপ্লিকেশনটি সমাপ্ত করা উচিত।

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


আমি শেষ অংশে অ্যাপ্লিকেশন সম্পর্কে কিছু প্রসঙ্গ তথ্য যুক্ত করার চেষ্টা করেছি।
জোনাস বেনজ

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

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

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

1
উইন্ডোজ ৩.১ এর আওতায় জোনাসবেজ, ডায়ালগ বাক্সটি উপস্থিত হয়েছিল যখন কোনও প্রোগ্রাম একটি অবৈধ মেমরি অ্যাক্সেস সম্পাদন করে তখন একটি "উপেক্ষা" বোতাম ছিল যা প্রোগ্রামটি চালিয়ে যেতে দেয়। আপনি লক্ষ করবেন যে উইন্ডোজের পরবর্তী প্রতিটি সংস্করণে সেই বোতামটি নেই।
চিহ্নিত করুন

12

বিবেচনা করে যে এটি রাসায়নিক পরীক্ষাগারের জন্য এবং আপনার অ্যাপ্লিকেশনটি সরাসরি নয় বরং অন্যান্য পরিষেবাদিগুলির মাধ্যমে যন্ত্রগুলি নিয়ন্ত্রণ করে না:

বার্তাটি দেখানোর পরে অবসান বন্ধ করুন। একটি অপরিবর্তিত ব্যতিক্রমের পরে আপনার অ্যাপ্লিকেশনটি অজানা অবস্থায় রয়েছে। এটি ভুল কমান্ড প্রেরণ করতে পারে। এমনকি এটি অনুনাসিক দানবদেরও আহ্বান করতে পারে । একটি ভ্রান্ত কমান্ড সম্ভাব্য ব্যয়বহুল reagents নষ্ট করতে পারে বা সরঞ্জাম বা লোকদের জন্য বিপদ ডেকে আনতে পারে

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

সম্পাদনা:

মন্তব্যে যেমন বলা হয়েছে, আপনি যে প্রক্রিয়াটি নিয়ন্ত্রণ করেন তার জন্য দ্রুত পর্যাপ্ত পরিমাণে পরিবর্তনগুলি প্রয়োজন হতে পারে যা ব্যবহারকারীর প্রতিক্রিয়া জানাতে সময় পাবে না। সেক্ষেত্রে আপনার মনোমুগ্ধকর অবস্থা পুনরুদ্ধারের পাশাপাশি অ্যাপটি নিঃশব্দে পুনঃসূচনা করার কথা বিবেচনা করা উচিত।


এমন একটি রাজ্যে সমাপ্তি যার জন্য অনুসরণ করা কমান্ডের অধিকার এখনই রাসায়নিক গবেষণাগারে যেমন বিপজ্জনক হতে পারে।
ওলেগ ভি। ভলকভ

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

@ ওলেগভি.ভলকভ যদিও এটি একটি ভাল বিষয়, তাই আমি উত্তরে এ সম্পর্কে আমার মতামত যুক্ত করেছি।
জান দর্নিয়াক

8

প্রোগ্রামের শীর্ষ স্তরে এই প্রশ্নের উত্তর দেওয়ার চেষ্টা করা কোনও স্মার্ট নাটক নয়।

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

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

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

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

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


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

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

3

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

যে কারণে, আপনার আবেদনটি শেষ করা উচিত।

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

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

একটি ভাল, যদিও এটি আর প্রাসঙ্গিক উদাহরণ নয়, ফায়ারফক্সের কিছু পুরানো সংস্করণ যা ক্রাশ থেকে পুনরুদ্ধার করার সময় কেবল দ্রুত শুরু হয় না , সেভাবে আরও ভাল স্টার্টআপের অভিজ্ঞতাও রয়েছে ! এই সংস্করণগুলিতে, আপনি যদি ফায়ারফক্সটি স্বাভাবিকভাবে বন্ধ করে রাখেন তবে এটি সমস্ত খোলা ট্যাবগুলি বন্ধ করে দেবে এবং একটি ফাঁকা ট্যাব শুরু করবে। ক্র্যাশ থেকে পুনরুদ্ধার করার সময়, এটি ক্র্যাশ হওয়ার সময় খোলা ট্যাবগুলি পুনরুদ্ধার করবে। (এবং এটি আপনার বর্তমান ব্রাউজিং প্রসঙ্গটি না হারিয়ে ফায়ারফক্সকে বন্ধ করার একমাত্র উপায় ছিল)) সুতরাং, লোকেরা কী করবে? তারা কখনও ফায়ারফক্স বন্ধ করে না এবং পরিবর্তে সর্বদা pkill -KILL firefoxএটি সম্পাদনা করে।

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

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


1

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

acquire lock
try
  update guarded resource
if exception
  invalidate lock
else
  release lock
end try

সুরক্ষিত সংস্থানটি আপডেট করার সময় যদি কোনও অপ্রত্যাশিত ব্যতিক্রম ঘটে তবে সংস্থানটি দুর্নীতিগ্রস্থ অবস্থায় ধরে নেওয়া উচিত এবং লকটি অবৈধ হওয়া উচিত, ব্যতিক্রমটি অন্যরকম সৌম্য হবে type

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


+1 কেবল সঠিক উপায়টি কী তা সম্পর্কে তুলনামূলকভাবে অপ্রত্যাশিত এবং এখনও অ-সাধারণ দৃষ্টিভঙ্গি প্রকাশ করার জন্য 1 আমি এটির সাথে একমত হয়েছি কিনা তা আমি এখনও জানি না, কারণ এটি আমার কাছে একটি উপন্যাসিক হিউরিস্টিক / নিয়ম, সুতরাং আমাকে এটি কিছুক্ষণের জন্য স্থির করে ফেলতে হবে, তবে এটি দৃ pla়ভাবে বুদ্ধিমান বলে মনে হয়।
mtraceur

0

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

আমার অভিজ্ঞতায় অনেক ব্যবহারকারী কোনও নোটিশ নেন না তবে কেবল অ্যাপ আইকনে ট্যাপ করে।

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.