সুরক্ষা বিধিনিষেধের কারণে কি কোনও পরিষেবা বাতিল হয়ে যায় বা একটি ব্যতিক্রম ছুঁড়ে ফেলে? [বন্ধ]


11

আমি এই বিষয়ে আরও অভিজ্ঞ বিকাশকারী সাথে কিছুটা দ্বিমত পোষণ করছি এবং অন্যরা এ সম্পর্কে কী ভাববে তা অবাক করে দিচ্ছি; আমাদের পরিবেশটি জাভা, ইজেবি 3, পরিষেবাদি ইত্যাদি is

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

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

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

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



@ ক্রিসএফ: 1) হ'ল লোকগুলি সম্পর্কে নালাগুলি বাদ দেয় যা আমি করি না। বেশিরভাগ ক্ষেত্রে এগুলি উপযুক্ত, আমি কেবল তাদের মধ্যে নেই বলে মনে করি না। 2) প্যারামিটারগুলি যাচাই করার বিষয়ে, এবং কোনও ব্যতিক্রম ছোঁড়ার মতো ফলাফলের উপর নির্ভর করে না? ৩) ত্রুটি কোড বনাম ব্যতিক্রমগুলিও একটি আলাদা সমস্যা কারণ তারা উভয়ই কী দেখায় ভুল হয়েছে "দেখানোর" উপায়। ত্রুটি কোডগুলি উপযুক্ত যদি উদাহরণস্বরূপ আপনার এমন কোনও সিস্টেমকে অবহিত করা দরকার যা ব্যতিক্রমগুলি সমর্থন করে না বা যদি আপনি শেষ ব্যবহারকারীকে কোড ব্যতীত অন্য কিছু দেখতে চান না।
Svish

আমি এখানে যে বিষয়টি জিজ্ঞাসা করছি তা হ'ল "কিছু উপস্থিতির অস্তিত্ব বা ঘটেনি" বলে "বনাম" কেন কিছু উপস্থিত নেই বা ঘটেছিল না তা জানিয়ে "।
Svish

3
আমি সেগুলি সদৃশ বলে প্রস্তাব দিইনি - কেবলমাত্র তারা আপনার জন্য দরকারী তথ্য থাকতে পারে।
ক্রিসএফ

সত্য, এর জন্য দুঃখিত! এটি কোনও কারণে "সম্ভাব্য নকল" মন্তব্য হিসাবে গ্রহণ করেছে ... সম্ভবত ঘুমের অভাবের কারণেই, তিনি।
সুইভিশ

উত্তর:


19

ব্যতিক্রম কেবল তখনই ছুঁড়ে ফেলা উচিত যখন কোনও ত্রুটি রয়েছে এবং কোনও জিনিস জিজ্ঞাসা করা ত্রুটি নয়।

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

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

String.substring()IndexOutOfBoundsExceptionসূচক সীমার বাইরে থাকলে একটি ছুড়ে দেয় । আমি nullপরিবর্তে ফিরে আসার কোনও সুবিধার কথা ভাবতে পারি না , যদিও - দার্শনিকভাবে - কেউ তর্ক করতে পারে যে একটিতে Stringতার সীমানার বাইরে কিছু নেই, তাই তাত্ক্ষণিকভাবে nullএকটি যৌক্তিক রিটার্ন মান হবে। যৌক্তিক-দার্শনিক হওয়া এবং ব্যবহারিক হওয়া অবশ্যই দুটি পৃথক প্রাণী।


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

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

@ কেভিঙ্কলাইন: যদি না কেউ এমন একটি কাঠামো ব্যবহার না করে যেখানে নাল রেফারেন্সটি একটি খালি স্ট্রিং ইঙ্গিত করার একটি মূ .় উপায়, আমি কোনও substringনাল রেফারেন্স ফিরে পাওয়ার কোনও ভিত্তি দেখতে পাচ্ছি না । আইএমএইচও, দুটি পৃথক ফাংশন থাকতে হবে - যার মধ্যে একটি হল অনুরোধ করা সংখ্যক চরিত্রের ফিরিয়ে দেওয়ার বা একটি ব্যতিক্রম ছুঁড়ে দেওয়ার প্রতিশ্রুতি দেয় এবং এর মধ্যে একটি তার যতটা সম্ভব ফিরে আসে। প্রতিটি পদ্ধতি কিছু প্রসঙ্গে অন্যের তুলনায় যথেষ্ট উন্নত হবে।
সুপারক্যাট

@ সুপের্যাট: নাল ফিরে আসার বিষয়ে আমি কিছু বলিনি। আমি বলেছিলাম 'ফিরে ... অংশ ... সম্ভবত খালি'। ওরাকল ব্যতীত একটি খালি স্ট্রিং নাল নয়।
কেভিন ক্লিন

@ জুনাসপুলাক্কা: আমার আগের মন্তব্যে আপনাকে পিন করা উচিত ছিল।
সুপারক্যাট

5

চুক্তি কী তা নেমে আসে। যদি আপনার চুক্তিটি বলে যে আপনি এমন কোনও কিছুর জন্য অনুরোধ করতে পারেন যা বিদ্যমান নেই, তবে এটি হওয়া উচিত যা ঘটেছিল (নাল, বা নাল বস্তু) object

অন্যদিকে, যদি আপনার চুক্তিটি বলে যে আপনাকে প্রথমে একটি আলাদা পদ্ধতি কল করা উচিত ( DoesSomethingExist()) এবং তারপরে পদ্ধতিটি কল করা উচিত Get, তবে আপনার চুক্তি বলতে পারে যে আপনি কেবল বিদ্যমান জিনিসগুলি পেতে পারেন, এবং যদি তা না করেন তবে ব্যতিক্রম নিক্ষেপ করতে পারেন। ব্যতিক্রম বার্তাটি এমন কিছু বলতে পারে, " DoesSomethingExist()প্রথমে কল করা নিশ্চিত করুন " এটি একটি দরকারী ত্রুটি বার্তা।


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

4

প্রশ্নের একক-আকারের-ফিট-সব উত্তর নেই। ব্যতিক্রম ব্যবহার করতে হবে বা নাল ফিরে আসা পরিস্থিতি উপর নির্ভর করে।

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

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

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

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

কোনও আইটেম তৈরির জন্য, তবে এটি একটি ভিন্ন গল্প। সম্ভবত এটি ব্যর্থ হওয়ার জন্য অনেকগুলি কারণ থাকতে পারে - কোনও অনুমতি, খারাপ পরামিতি, মেমরির বাইরে থাকা সার্ভার ইত্যাদি নয় If ।

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

সুতরাং, এটি নিয়ে কোনও ধর্মীয় যুদ্ধে জড়িয়ে পড়বেন না, এই বিশেষ সমস্যার জন্য উপযুক্ত কি তা ঠিক করুন।


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

1
এবং একজন বিকাশকারী হিসাবে আমি কেন কিছু ভুল, সে সম্পর্কে শেষ ব্যবহারকারীকে কী জানানো উচিত তা নির্বিশেষে যত্নবান।
Svish

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

3

আমি অবশ্যই মনে করি এটি একটি খারাপ নকশা । নাল-পয়েন্টার আমার কাছে বৈধ উত্তর নয় এবং এটি পরিচালনা করা জটিল y

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

নেটওয়ার্ক লিঙ্কটি নষ্ট হয়ে গেলে বা অন্যান্য অপ্রত্যাশিত সমালোচনামূলক ত্রুটি হলে আপনার নালীর উত্তরটি ছেড়ে দেওয়া উচিত।

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


আপনার শেষ বাক্যটির দ্বারা, আপনি কী বোঝাতে চেয়েছেন " নেটওয়ার্ক লিঙ্কটি নষ্ট হয়ে গেলেই আপনার নালাগুলি ফিরে আসা উচিত " " বা " নেটওয়ার্কের লিঙ্কটি নষ্ট হয়ে গেলে আপনার নালায় ফিরে আসা উচিত " " ?
পিটার টারিক

@ পিটার টার্ক: আমি "রিটার্ন নাল;" এর স্পষ্ট ব্যবহারের পরামর্শ দিচ্ছি না। তবে যখন কোনও বড় ব্রেকডাউন ঘটে তখন কিছু পরিষেবার শূন্য হওয়া ফিরে গ্রহণযোগ্য।
আমিন

কোনও অপ্রত্যাশিত সমালোচনাজনিত সমস্যা দেখা দিলে ব্যতিক্রম কি আরও উপযুক্ত হবে না?
Svish

2
@ আমিন: আমি বলব যে এটি ন্যূনতম ফিরে আসার জন্য সবচেয়ে উপযুক্ত উপযুক্ত মামলা।
মাইকেল বর্গওয়ার্ট

@ সুইশ: আপনি যদি প্রধান ব্রেকডাউন সনাক্ত করতে পারেন তবে অবশ্যই একটি ব্যতিক্রম দুর্দান্ত।
আমিনে

3

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

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

অন্যদিকে, ফিরিয়ে দিয়ে nullআপনি ক্লায়েন্টকে কী চলছে তা তদন্ত করতে বাধ্য করুন।

তদতিরিক্ত, আপনি বুঝতে পেরেছিলেন যে কোনও সমস্যা হয়েছে কারণ আপনি অন্য কোথাও পেয়ে গেছেন a NullPointerException। এখন কল্পনা করুন আপনি সেই ফাংশনটির রিটার্ন সংরক্ষণ করবেন না ... আপনি সেই ফাংশনটিতে প্রতিটি কলকে একটি if elseব্লক দিয়ে ঘিরে ফেলতে বাধ্য হবেন ...

আমার দৃষ্টিকোণ থেকে, ফিরে আসা nullএকটি খারাপ অভ্যাস।


2

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

আমার দৃষ্টিকোণ থেকে, এটি কোনও মানে করে না।

অনুমতি ছাড়া ডেটার জন্য অনুসন্ধান করা উচিত , একটি ব্যতিক্রম ঘটাতে কারণ এটি একটি হল অপ্রত্যাশিত ফলাফলের - কোনো ফলাফল পেতে - সঠিক অ্যাক্সেস ছাড়া।

সাদৃশ্য : GETঅনুমোদন ছাড়াই একটির জন্য প্রতিক্রিয়া কোড 200 okকোনও ডেটা সহ নয়, এটি আসলে 401 Unauthorized


1

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

একটি অর্থবহ প্রতিক্রিয়া অ্যাপ্লিকেশনটিকে পরবর্তী কী করবেন বা কীভাবে সমস্যাগুলি সমাধান করবেন সে সম্পর্কে যৌক্তিক পছন্দগুলি করার অনুমতি দিতে পারে।


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

"সিস্টেমের ডিজাইনের প্রয়োজন যা আপনি জানেন না" এর অর্থ কী? এটি কী ধরণের ডিজাইন হতে পারে?
Svish

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

1

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

ব্যতিক্রম কেবল ব্যতিক্রমী সিরামাস্তে ব্যবহার করা উচিত এবং এর অর্থ এই যে কোনও কিছু ভুল হয়েছে। আমি অসম্মতি জানাই যে তারা "অনুমোদিত নয়" মানে ওভারলোড হওয়া উচিত। (নাল রিটার্ন মানের ক্ষেত্রেও এটি একই: আমি এটি অনুমোদিত "না" বোঝাতে ব্যবহার করা উচিত বলে একমত নই।)


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

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

0

শয়তানদের উকিল খেলতে আমি নালার দিকে ফিরে যাওয়ার চেষ্টা করব to

আমার মতে একটি মাত্র পরিস্থিতি রয়েছে যেখানে এই ধরণের প্রতিক্রিয়া প্রায় গ্রহণযোগ্য এবং তা হ'ল এই ক্ষেত্রে যেমন সুরক্ষা জড়িত থাকে।

দুর্ঘটনাক্রমে আপনার সিস্টেমের বিশদ বিবরণ দেওয়া খুব সহজ যেটি অননুমোদিত লোকদের সম্পর্কে জানা উচিত নয়। এটি এড়ানো উচিত।

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

সুতরাং, এই বিশেষ ক্ষেত্রে আমি বলব যে এটি ফিরে আসা প্রায় ঠিক আছে nullতবে আমি সম্মত, এটির সাথে কাজ করা খুব অপ্রীতিকর হবে।


হ্যাঁ, আমি দ্বিমত পোষণ করব। আমার মতে সেখানে যথাযথ প্রতিক্রিয়া ব্যতিক্রম হতে পারে তবে ব্যবহারকারীর নাম এবং ভুল পাসওয়ার্ড উভয়ের ক্ষেত্রে একইরকম one ব্যর্থযুক্ত তলোগিন, যা-ই হোক না কেন, অবৈধ সনদপত্র।
Svish

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

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

1
এবং লগইনের উদাহরণ সহ আমি বলব যে তারা ব্যবহারকারীর অভিজ্ঞতার পক্ষে কমপক্ষে কিছু না বলে কেন তারা (ভেবেছিল) তাদের শংসাপত্রগুলি প্রবেশ করায় কেন কিছুই ঘটেনি বলে মনে হচ্ছে তা খারাপ। পৃষ্ঠাটি যদি সতেজ হয় এবং মনে হয় এটি কেবল আমার লগ ইন করার প্রয়াসকে অগ্রাহ্য করেছে, আমি ধরে নেব যে সিস্টেমে কিছু ভুল হয়েছে, আমি যা লিখেছি তা ভুল ছিল না।
Svish

-2

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

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