ইলিজালস্টেট এক্সেকশন বা নীরব পদ্ধতি কার্যকরকরণ কী? [বন্ধ]


16

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

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


21
মডেল আচরণে ব্যতিক্রমগুলি ব্যবহার করবেন না এটি ব্যতিক্রমী নয়।
আলেকজান্ডার - মনিকা

1
হে! আমি এটি একটি সদৃশ মনে করি না। আমার প্রশ্নটি ইলিজালস্টেট এক্সেপশন সম্পর্কে আরও বেশি এবং উপরের প্রশ্নটি সাধারণভাবে ব্যতিক্রমগুলি ব্যবহার করার বিষয়ে।
x2bool

1
শুধু নীরবে চুপচাপ ব্যর্থ হওয়ার পরিবর্তে, কেন ALSO সতর্কতা হিসাবে অসাধারণত লগ না করে? অবশ্যই আপনি যে জাভা ব্যবহার করছেন তা বিভিন্ন লগ স্তরের (ERROR, WARN, INFO, DEBUG) সমর্থন করে।
এরিক সিস্ট্র্যান্ড 20

3
লক্ষ্য করুন যে আইটেমটি ইতিমধ্যে সেটে থাকলে সেট.এডডি একটি ব্যতিক্রম ছুঁড়ে না। "সেটে উপাদানটি সেটে রয়েছে তা নিশ্চিত করা" এর উদ্দেশ্য এর উদ্দেশ্য, "আইটেমে আইটেমটি সংযুক্ত করুন" এর পরিবর্তে এটি উপাদানটি ইতিমধ্যে সেটে থাকলে কিছুই না করে তার উদ্দেশ্য অর্জন করে।
ব্যবহারকারী 253751

2
দিনের শব্দ: আদর্শশক্তি
জুলস

উত্তর:


37

কোনও নিয়ম নেই। আপনি কীভাবে আপনার এপিআই "বোধ" করতে চান তা সম্পূর্ণরূপে up

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

আরও "মিশ্রযোগ্য" পদ্ধতির স্বীকৃতি হ'ল রূপান্তরটি সবচেয়ে ক্ষতিকারক নয় এবং আপনার গ্রাহক বিকাশকারীদের এটির অনুমতি দিয়ে দয়া করে।

সুতরাং, যদি এটি আমার উপর নির্ভর করে তবে আমি ব্যতিক্রমটি এড়িয়ে যাতাম।


15
এই উত্তরটি আমাদের মনে করিয়ে দেয় যে কখনও কখনও এমনকি সরল ইন্টারঅ্যাকশনের জন্যও রাষ্ট্রের রূপান্তরগুলি স্কেচ করা ভাল ধারণা।

6
এটি মনে রেখে, একটি ব্যতিক্রম ছোঁড়া পেডেন্টিক এবং অন্যায় বলে মনে হবে। এটি স্কুল বাসে বিরক্তিকর বাচ্চাদের সাথে কথা বলার সামাজিক সমতুল্যর মতো এপিআইটিকে অনুভব করবে। > ব্যতিক্রমগুলি আপনাকে শাস্তি দেওয়ার জন্য ডিজাইন করা হয়নি: সেগুলি আপনাকে অপ্রত্যাশিত কিছু ঘটতে বলার জন্য ডিজাইন করা হয়েছে। আমি ব্যক্তিগতভাবে এমন একটি পদ্ধতির জন্য অত্যন্ত কৃতজ্ঞ হব MediaPlayer.stop()যা IllegalStateExceptionডিবিগিং কোডের কয়েক ঘন্টা ব্যয় করার পরিবর্তে এবং কেন ভাবছে যে হেল "কিছুই হয় না" (অর্থাত "এটি কেবল কাজ করে না") ভেবে অবাক হব ।
ভুল কাজ

3
অবশ্যই, যদি আপনার নকশাটি লুপব্যাক স্থানান্তরটি অবৈধ বলে থাকে তবে হ্যাঁ আপনার একটি ব্যতিক্রম ছুঁড়ে ফেলা উচিত। তবে আমার উত্তরটি এমন একটি ডিজাইন সম্পর্কে ছিল যেখানে সেই রূপান্তরটি পুরোপুরি ঠিক।
মেটাফাইট

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

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

17

এখানে দুটি স্বতন্ত্র ধরণের ক্রিয়া সম্পাদন করতে ইচ্ছুক হতে পারে:

  1. একই সাথে পরীক্ষা করুন যে কোনও জিনিস একটি অবস্থায় রয়েছে এবং এটিকে অন্য অবস্থায় পরিবর্তন করুন।

  2. পূর্ববর্তী রাষ্ট্রের জন্য বিবেচনা না করে একটি নির্দিষ্ট রাজ্যে কিছু সেট করুন।

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

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


2
পুরাতন অবস্থায় ফিরে আসার বিষয়ে নোটের জন্য +1: এটি এটিকে এমনভাবে প্রয়োগ করতে দেয় যা পুরো অপারেশনকে (স্থিতি জিজ্ঞাসা করে এবং সংজ্ঞায়িত স্থিতিতে রূপান্তর করে) পারমাণবিক করে তোলে যা খুব কমপক্ষে একটি সুন্দর বৈশিষ্ট্য। শক্তিশালী ব্যবহারকারীর কোডটি লিখতে এটি আরও সহজ করে তুলবে যা কিছু অদ্ভুত জাতি অবস্থার কারণে বিক্ষিপ্তভাবে ব্যর্থ হয় না।
cmaster - পুনর্বহাল মনিকা

একটি bool TryStop()এবং একটি void Stop()কোড উদাহরণ এটিকে সত্যই চমৎকার উত্তর হিসাবে তৈরি করবে।
রাবারডাক

2
@ রাবারডাক: এটি ভাল প্যাটার্ন হবে না। নামটি TryStopবোঝায় যে খেলোয়াড়কে থামানো অবস্থায় বাধ্য করা না হলে ব্যতিক্রম ছোঁড়া উচিত নয়। প্লেয়ারটি ইতিমধ্যে বন্ধ হয়ে গেলে থামানোর চেষ্টা করা ব্যতিক্রমী শর্ত নয়, তবে একজন শর্ত একজন কলার আগ্রহী।
সুপারক্যাট

1
তারপর আমি আপনার উত্তর @supercat অনেকেই ভুল বুঝে ভাবেন থাকেন
RubberDuck

2
আমি উল্লেখ করতে চাই যে এইভাবে পরীক্ষা করা এবং সেট করা ডিমেটারের আইন লঙ্ঘন নয়, তবে এআইপিআই পরিবর্তন না করে প্লেব্যাকের স্থিতি পরীক্ষা করার উপায় সরবরাহ করে। এটি সম্পূর্ণ ভিন্ন পদ্ধতি হতে পারে, বলুন isPlaying()
candied_orange

11

কোনও সাধারণ নিয়ম নেই। এই নির্দিষ্ট ক্ষেত্রে, আপনার API এর ব্যবহারকারীর উদ্দেশ্য হল প্লেয়ারটিকে মিডিয়া খেলতে বাধা দেওয়া। যদি প্লেয়ার মিডিয়া খেলছে না, তবে এটি MediaPlayer.stop()কিছুই করতে পারে না এবং পদ্ধতি কলারের লক্ষ্য এখনও অর্জন করা যাবে - মিডিয়া খেলছে না।

একটি ব্যতিক্রম ছুঁড়ে ফেলার জন্য প্লেয়ারটি বর্তমানে খেলছে কিনা বা ব্যতিক্রমটি ধরা ও পরিচালনা করছে কিনা তা খতিয়ে দেখার জন্য এপিআইয়ের ব্যবহারকারীর প্রয়োজন। এটি ব্যবহারের জন্য এপিআইকে আরও কাজ করে তোলে।


11

ব্যতিক্রমগুলির উদ্দেশ্যটি হ'ল সংকেত দেওয়া নয় যে খারাপ কিছু ঘটেছে; এটা যে সিগন্যাল

  1. কিছু খারাপ হয়েছে
  2. আমি এখানে ঠিক করতে জানি না
  3. যে কলার, বা এটি থেকে কলস্ট্যাকের কিছু আপ কীভাবে মোকাবেলা করতে হবে তা জানা উচিত
  4. সুতরাং আমি দ্রুত জামিন দিচ্ছি, ক্ষতি বা তথ্য দুর্নীতি রোধ করার জন্য বর্তমান কোডপথটি কার্যকর করা বন্ধ করে দিচ্ছি এবং এটি পরিষ্কার করার জন্য কলারের কাছে রেখে দিচ্ছি

থাকলে আহ্বানকারী চেষ্টা Stopএকটি MediaPlayerএকটি থামানো রাষ্ট্র ইতিমধ্যই থাকা যে, এই একটা সমস্যা হয় না যে MediaPlayerনারা সমাধানে (এটা কেবল কিছুই করতে পারেন।) এটি একটি সমস্যা যে, যদি অব্যাহত, ক্ষতি বা তথ্য হতে হবে নয় দুর্নীতি, যেহেতু এটি কিছুই না করে কেবল সফল হতে পারে। আর এটি আসলেই কোনও সমস্যা নয় যে কলারটি এর চেয়ে সমাধান করতে সক্ষম হবে এমনটি আশা করা আরও যুক্তিসঙ্গত MediaPlayer

অতএব, এই পরিস্থিতিতে আপনার কোনও ব্যতিক্রম ছোঁড়া উচিত নয়।


+1 টি। এটি প্রথম উত্তর যা দেখায় যে এখানে কেন ব্যতিক্রম উপযুক্ত নয়। ব্যতিক্রমগুলি ইঙ্গিত দেয় যে কলারটির ব্যতিক্রমী কেস সম্পর্কে জানা থাকা সম্ভবত। এই ক্ষেত্রে, প্রায় অবশ্যই প্রশ্নে ক্লাসের ক্লায়েন্ট "স্টপ ()" কল করা আসলে কোনও রাষ্ট্রীয় রূপান্তর ঘটেছে কিনা সেদিকে খেয়াল রাখে না, তাই সম্ভবত কোনও ব্যতিক্রম সম্পর্কে জানতে চান না।
জুলস

5

এটাকে এইভাবে দেখ:

প্লেয়ারটি খেলতে না পারলে ক্লায়েন্ট যদি স্টপ () কে কল করে তবে স্টপ () স্বয়ংক্রিয়ভাবে সফল হয় কারণ প্লেয়ারটি বর্তমানে বন্ধ অবস্থায় রয়েছে।


3

নিয়মটি হ'ল আপনি যা করেন আপনার পদ্ধতির চুক্তির জন্য প্রয়োজনীয়।

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

আপনি কোনও ব্যতিক্রম নিক্ষেপ করতে চান এমন কোনও কারণ আছে কি ? যদি ব্যবহারকারীর কোডটি শেষ পর্যন্ত দেখতে পাওয়া যায়:

try {
    player.stop();
} catch(IllegalStateException e) {
    // do nothing, player was already stopped
}

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

খেলোয়াড় পর্যবেক্ষণযোগ্য হতে পারে, এবং ইতিমধ্যে কিছু জিনিস সম্পর্কে পর্যবেক্ষক অবহিত পারে - যেমন জ্ঞাপক পর্যবেক্ষক যখন তা থেকে transitons playingকরার stoppingজন্য stopped। এই ক্ষেত্রে, পদ্ধতিটি একটি ব্যতিক্রম নিক্ষেপ করা প্রয়োজনীয় নয়। কল করা হচ্ছে stopমাত্র যদি খেলোয়াড় ইতিমধ্যে বন্ধ থাকে কিছুই করতে হবে, এবং এটি কলিং যখন তার স্থানান্তরের বিষয়ে পর্যবেক্ষক অবহিত করা হবে থামানো।

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

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


3

একটি সাধারণ সাধারণ কৌশল রয়েছে যা আপনাকে এই সিদ্ধান্ত নিতে সহায়তা করে।

যদি বাদ দেওয়া হয় তবে কীভাবে ব্যতিক্রম পরিচালনা করা হবে তা বিবেচনা করুন।

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

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

এটি কেবল ব্যতিক্রমগুলির ক্ষেত্রেই প্রযোজ্য নয় তবে কোনও প্রকারের শাখা প্রশাখা: মূলত যদি আচরণে কোনও পর্যবেক্ষণযোগ্য পার্থক্য না প্রয়োজন হয় তবে শাখা প্রশাখার দরকার নেই।

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


2

অ্যান্ড্রয়েড এটি কী করে তা এখানে রয়েছে: মিডিয়াপ্লেয়ার

সংক্ষেপে, stopযখন startডাকা হয় নি কোনও সমস্যা নয়, সিস্টেমটি বন্ধ অবস্থায় রয়েছে, তবে যদি এমন খেলোয়াড়কে ডাকা হয় যে এটি কী খেলছে তাও জানে না, একটি ব্যতিক্রম ছুঁড়ে দেওয়া হয়, কারণ কল করার কোনও ভাল কারণ নেই ওখানে থামো.


1

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

আমি দেখছি যে আপনার বিবৃতিতে একটি সামান্য বৈপরীত্য হতে পারে যা উত্তরটি আপনার কাছে পরিষ্কার করে দিতে পারে। কেন এই পদ্ধতিটি কল করার কথা নয় এবং তবুও এর প্রয়োগের কোনও ক্ষতি হয় না ?

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

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

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

আপনার ক্ষেত্রে, যদি আপনার রাষ্ট্রীয় মেশিনটি অবৈধ / অপ্রয়োজনীয় কল পরিচালনা করতে পারে তবে এটিকে উপেক্ষা করুন, অন্যথায় একটি ত্রুটি নিক্ষেপ করুন।

সম্পাদনা করুন:

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


এটি কল করার কথা নয় কারণ এটি কল করা কলকারী একটি বাগ নির্দেশ করে।
ব্যবহারকারী 253751

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

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

@ ইমিবিস - আমি আমার প্রতিক্রিয়া সম্পাদনা করেছি। আমি আসা করি এটা সাহায্য করবে.
জিম

1

ঠিক কী করবেন MediaPlayer.play()এবং MediaPlayer.stop()করবেন? - তারা ব্যবহারকারীর ইনপুটটির জন্য ইভেন্ট শ্রোতা নাকি সেগুলি আসলে এমন পদ্ধতি যা সিস্টেমে কোনও ধরণের মিডিয়া স্ট্রিম শুরু করে? যদি তারা সকলেই ব্যবহারকারীর ইনপুটটির জন্য শ্রোতা হয় তবে তাদের পক্ষে কিছুই না করা পুরোপুরি যুক্তিসঙ্গত (যদিও এটি কমপক্ষে কোথাও তাদের লগইন করা ভাল ধারণা হবে)। তবে, যদি তারা আপনার ইউআই নিয়ন্ত্রণ করছে এমন মডেলটিকে প্রভাবিত করে , তবে তারা একটি ছুঁড়ে ফেলতে পারে IllegalStateExceptionকারণ প্লেয়ারটির কিছু প্রকার isPlaying=trueবা isPlaying=falseঅবস্থা থাকতে হবে (এটি এখানে লিখিত মতো সত্যিকারের বুলিয়ান পতাকা হওয়া উচিত নয়), এবং যখন আপনি কল করবেন MediaPlayer.stop()তখন isPlaying=false, পদ্ধতিটি আসলে "থামাতে" পারে না MediaPlayerকারণ বস্তুটি থামানোর জন্য যথাযথ অবস্থায় নেই - এর বিবরণ দেখুনjava.lang.IllegalStateException শ্রেণী:

একটি পদ্ধতি অবৈধ বা অনুপযুক্ত সময়ে চালিত হওয়ার ইঙ্গিত দেয় als অন্য কথায়, জাভা পরিবেশ বা জাভা অ্যাপ্লিকেশন অনুরোধকৃত ক্রিয়াকলাপের জন্য উপযুক্ত অবস্থায় নেই।

কেন ব্যতিক্রম ছোঁড়া ভাল হতে পারে

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

তারপরে, একদিন কোডটিতে কাজ করার সময়, আমি "প্লে" ক্লিক করি এবং কিছুই ঘটে না। যদি MediaPlayerGUIController.notifyPlayButton()কিছু লগ হয় তবে কমপক্ষে আমি লগগুলিতে সন্ধান করতে পারি এবং বোতাম ক্লিকটি বাস্তবে নিবন্ধিত ছিল কিনা তা পরীক্ষা করতে পারি ... তবে কেন এটি প্লে হয় না? ঠিক আছে, বলুন আসলে পালস অডিও র‍্যাপারগুলির মধ্যে কিছু ভুল আছে যা MediaPlayer.play()ডাকে। আমি আবার "প্লে" বোতামটি ক্লিক করি এবং এবার আমি একটি পেয়েছি IllegalStateException:

 Exception in thread "main" java.lang.IllegalStateException: MediaPlayer already in play state.

     at org.superdupermediaplayer.MediaPlayer.play(MediaPlayer.java:16)
     at org.superdupermediaplayer.gui.MediaPlayerGUIController.notifyPlayButton(MediaPlayerGUIController.java:25)
     at org.superdupermediaplayer.gui.MediaPlayerGUI.main(MediaPlayerGUI.java:14)

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

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


0

আমি এমনভাবে এপিআই ডিজাইন করতে পছন্দ করি যা ভোক্তাদের পক্ষে ভুল করা শক্ত বা অসম্ভব হয়ে পড়ে। উদাহরণস্বরূপ, থাকার MediaPlayer.play()এবং পরিবর্তে MediaPlayer.stop(), আপনি MediaPlayer.playToggle()"থামিয়ে দেওয়া" এবং "খেলতে" এর মধ্যে যে টগলগুলি সরবরাহ করতে পারেন । এইভাবে, পদ্ধতিটি কল করা সর্বদা নিরাপদ - অবৈধ অবস্থায় যাওয়ার কোনও ঝুঁকি নেই।

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

  • এটি সম্পর্কে বাস্তববাদী এবং কোনও ত্রুটি নিক্ষেপ করবেন না। এটি অবশ্যই প্রচুর কোডকে সহজতর করে, উদাহরণস্বরূপ, if (list.contains(x)) { list.remove(x) }কেবলমাত্র আপনার কেবল লেখার দরকার নেই list.remove(x))। তবে এটি বাগগুলিও আড়াল করতে পারে।
  • অথবা আপনি পেডেন্টিক হতে পারেন এবং একটি ত্রুটি সংকেত করতে পারেন যে তালিকায় সেই উপাদানটি নেই। কোডটি সময়ে সময়ে আরও জটিল হয়ে উঠতে পারে, কারণ পদ্ধতিটি কল করার আগে আপনাকে নিয়মিত শর্তাদি সন্তুষ্ট কিনা তা আপনাকে ক্রমাগত যাচাই করতে হবে, তবে উল্টোটি হল যে শেষের বাগগুলি ট্র্যাক করা সহজ।

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


3
playToggle()ব্যবহারে সহজ হওয়া সম্পর্কে আমি একমত নই : পছন্দসই প্রভাব অর্জন করতে (প্লেয়ার খেলছেন বা না খেলছেন), আপনার বর্তমান অবস্থাটি জানতে হবে। সুতরাং, যদি আপনি ব্যবহারকারীর ইনপুটটি আপনাকে প্লেয়ারটি থামানোর অনুরোধ জানায় তবে প্রথমে আপনাকে প্লেয়ারটি বর্তমানে খেলছে কিনা তা অনুসন্ধান করতে হবে, তারপরে তার রাজ্যে টগল করুন বা উত্তরের উপর নির্ভর করে না। এটি কেবল একটি stop()পদ্ধতি কল করার চেয়ে এটি আরও জটিল এবং এটির সাথে সম্পন্ন করা।
মাস্টার - মোনিকা

ভাল আমি কখনও বলিনি যে এটি ব্যবহার করা সহজ ছিল - আমার দাবিটি এটি নিরাপদ। এছাড়াও, আপনার উদাহরণ ধরে নেওয়া হয়েছে যে ব্যবহারকারীকে পৃথক স্টপ এবং প্লে বোতাম দেওয়া হবে। যদি তা প্রকৃতপক্ষে হয় তবে হ্যাঁ, playToggleএটি ব্যবহার করা খুব জটিল umbers তবে যদি ব্যবহারকারীকে পরিবর্তে একটি টগল বোতামও দেওয়া হয়, তবে playToggleপ্লে / স্টপ করার চেয়ে ব্যবহার করা আরও সহজ।
পেড্রো রডরিগস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.