সীমার বাইরে অর্থবহ মানের ক্ষেত্রে আমার কি ব্যতিক্রম ছুঁড়ে ফেলা উচিত বা নিজেই এটি পরিচালনা করতে হবে?


42

আমি একটি কাঠামো লিখেছি যা অক্ষাংশ / দ্রাঘিমাংশ স্থানাঙ্কগুলিকে প্রতিনিধিত্ব করে। তাদের মানগুলি দ্রাঘিমাংশের জন্য -180 থেকে 180 এবং ল্যাটিটুডগুলির জন্য 90 থেকে -90 অবধি রয়েছে।

যদি সেই কাঠামোর কোনও ব্যবহারকারী আমাকে এই ব্যাপ্তির বাইরে একটি মান দেয় তবে আমার কাছে দুটি বিকল্প রয়েছে:

  1. একটি ব্যতিক্রম নিক্ষেপ (পরিধি ছাড়াই আর্গুমেন্ট)
  2. সীমাবদ্ধতায় মান রূপান্তর করুন

কারণ -185 এর একটি স্থানাঙ্কের অর্থ রয়েছে (এটি খুব সহজেই +175 তে রূপান্তরিত হতে পারে কারণ এটি মেরু সমন্বয়কারী), আমি এটি গ্রহণ করতে এবং এটি রূপান্তর করতে পারতাম could

তার কোডটি আমাকে এমন একটি মান দিয়েছে যা তার উচিত নয়, তা বলার জন্য কি একটি ব্যতিক্রম ছুঁড়ে দেওয়া ভাল?

সম্পাদনা: এছাড়াও আমি ল্যাট / এলএনজি এবং স্থানাঙ্কগুলির মধ্যে পার্থক্যটি জানি, তবে আমি সহজ আলোচনার জন্য এটি সহজ করতে চেয়েছিলাম - এটি ধারণাগুলির মধ্যে সবচেয়ে উজ্জ্বল ছিল না


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

সি #, ব্যাপার কি? এটি মূলত বাধাগুলিকে সমর্থন করে না যদি এটি আপনি বোঝাতে চান।
কে। গকিনিস

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

2
আমি নির্দিষ্ট প্যারামিটার মানগুলি পাস করে ব্যবহারকারী কী বোঝাতে চেয়েছিল সে সম্পর্কে অনুমান করা থেকে দূরে থাকি, বিশেষত আমার কোডটি সেগুলি পূরণ করে না। অনুরূপ কেস মত শোনাচ্ছে।
JᴀʏMᴇᴇ

2
ওয়েব Mercator স্থানাঙ্ক হয় না -180 থেকে 180 এবং -90 90. করার অক্ষাংশ / দ্রাঘিমাংশ হল যে (এবং সেখানে যে জন্য এমনকি বিভিন্ন তুল্য সিস্টেম) এর। মার্কেটর অনুমানগুলি সাধারণত কয়েক হাজার বা লক্ষ লক্ষতে থাকে এবং এর ইউনিটগুলি "মিটার" থাকে (এমনকি কঠোরভাবে নয় যেহেতু প্রতিটি ইউনিটের দৈর্ঘ্য ক্রমবর্ধমান প্রকৃত স্থল দুরত্বকে আবদ্ধ করে আপনি খুঁটির কাছে যাওয়ার সময়) ডিগ্রি নয়। এমনকি ডিগ্রির ক্ষেত্রেও এটি ± 85.051129 ডিগ্রিতে সীমাবদ্ধ কারণ কারণ মেরুতে প্রজেকশন অসীম প্রশস্ত হয়। (আমি এটিকে সংশোধন করে একটি সম্পাদনা জমা দিয়েছি, কারণ এটি প্রশ্নের মূল বিষয় নয়।)
জেএমপিসি 26

উত্তর:


51

আপনার প্রশ্নের মূল যদি এটি হয় ...

যদি কিছু ক্লায়েন্ট কোড একটি আর্গুমেন্ট পাস করে যার মানটি আমার ডেটা স্ট্রাকচার মডেলিংয়ের জিনিসটির জন্য অবৈধ, আমি কি মানটিকে প্রত্যাখ্যান করব বা এটিকে বোধগম্য কিছুতে রূপান্তর করব?

... তাহলে আমার সাধারণ উত্তরটি "প্রত্যাখ্যান" হবে, কারণ এটি ক্লায়েন্ট কোডের সম্ভাব্য বাগগুলিতে মনোযোগ আকর্ষণ করতে সহায়তা করবে যা প্রকৃতপক্ষে প্রোগ্রামটিতে অবৈধ মানটির কারণ হিসাবে উপস্থিত হয় এবং আপনার নির্মাতাকে পৌঁছায়। কমপক্ষে বিকাশের সময় বাগের দিকে দৃষ্টি আকর্ষণ করা বেশিরভাগ সিস্টেমে সাধারণত একটি কাঙ্ক্ষিত সম্পত্তি হয় (যদি না এটি ত্রুটির ক্ষেত্রে আপনার সিস্টেমের কাঙ্ক্ষিত সম্পত্তি হ'ল)।

আপনি আসলে সেই মামলার মুখোমুখি হচ্ছেন কিনা তা প্রশ্ন ।

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

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

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


12
-180 থেকে +180 ব্যাপ্তির বাইরে একটি দ্রাঘিমাংশ সম্ভবত গ্রহণযোগ্য হিসাবে বিবেচনা করা উচিত, তবে -90 থেকে +90 পরিসরের বাইরে অক্ষাংশটি অযৌক্তিক বলে মনে হবে। একবার উত্তর বা দক্ষিণ মেরুতে পৌঁছালে উত্তর বা দক্ষিণে আরও ভ্রমণ অনির্ধারিত হয়।
সুপারক্যাট

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

1
@ সুপের্যাট: মেরিডিয়ান নিরক্ষীয় অঞ্চলে পৌঁছে যেখানে শুরু করুন start অক্ষাংশ অনুসারে মেরিডিয়ান বরাবর ভ্রমণ করুন। অক্ষাংশ যদি 90% হয় তবে কেবল একই দুর্দান্ত বৃত্ত ধরে চলুন। সমস্যা নেই. এটি নথি করুন এবং ক্লায়েন্টের কাছে বাকীটি ছেড়ে দিন।
কেভিন cline

4
@ সুপের্যাট এটি এর চেয়েও খারাপ। ওয়েব মার্কেটর প্রজেকশনে, ± 90 আসলে অসীম প্রস্থের জন্য অনুমান করা হয়। সুতরাং স্ট্যান্ডার্ডটি আসলে এটি 85.051129 ডলারে কেটে দেয়। এছাড়াও, ল্যাট / লম্বা! = ওয়েব মিটারের স্থানাঙ্ক। মার্কেটর স্থানাঙ্কগুলি মিটারের ভিন্নতা ব্যবহার করে, ডিগ্রি নয়। (আপনি খুঁটির কাছাকাছি যাওয়ার সাথে সাথে প্রতিটি "মিটার" প্রকৃতপক্ষে একটি বৃহত্তর এবং বৃহত্তর অংশের সাথে মিলে যায়)) ওপিএস স্থানাঙ্কগুলি খাঁটি লম্বা / দীর্ঘ। ওয়েব মার্কেটারের তাদের সাথে কোনও সম্পর্ক নেই, অন্যথায় তারা কোনও ওয়েব মার্কেটর বেস মানচিত্রের শীর্ষে প্রদর্শিত হতে পারে এবং কিছু স্থানিক গ্রন্থাগার তাদের জন্য হুডের নীচে প্রজেক্ট করছে।
jpmc26

1
আমার বলা উচিত "85.051129 ডলার সমতুল্য", যেহেতু এটি প্রকৃত স্থানাঙ্ক নয়।
jpmc26

10

এটি অনেকটা নির্ভর করে। তবে আপনার কিছু করা এবং এটি নথিভুক্ত করার সিদ্ধান্ত নেওয়া উচিত ।

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

এই ক্ষেত্রে আমি যেভাবেই যুক্তি দেখতে পাচ্ছি। যদি কেউ 175 ডিগ্রি থেকে +10 ডিগ্রি ভ্রমণ করে তবে তাদের -175 এ শেষ হওয়া উচিত। আপনি যদি সর্বদা ব্যবহারকারীর ইনপুটকে স্বাভাবিক রাখেন এবং 185 এর সাথে -175 এর সমতুল্য আচরণ করেন তবে ক্লায়েন্ট কোড 10 ডিগ্রি যুক্ত করলে ভুল কাজটি করতে পারে না ; এটি সর্বদা সঠিক প্রভাব ফেলে। যদি আপনি 185 কে ত্রুটি হিসাবে বিবেচনা করে থাকেন তবে প্রতিটি ক্ষেত্রেই ক্লায়েন্ট কোড নরমালাইজিক যুক্তিতে রাখার জন্য আপেক্ষিক ডিগ্রি যুক্ত করছে (বা কমপক্ষে আপনার স্বাভাবিকীকরণের পদ্ধতিটি কল করতে মনে রাখবেন), আপনি আসলে কারণ হবেনবাগগুলি (যদিও দ্রুত স্কোয়াশ করা হবে এমনগুলি সহজেই ধরা সহজ) তবে যদি একটি দ্রাঘিমাংশের নম্বর ব্যবহারকারী-প্রবেশ করানো হয়, প্রোগ্রামে আক্ষরিকভাবে লেখা হয়, বা সর্বদা [-180, 180) হওয়ার উদ্দেশ্যে কিছু পদ্ধতিতে গণনা করা হয়, তবে সেই ব্যাপ্তির বাইরে থাকা মানটি সম্ভবত একটি ত্রুটি নির্দেশ করে, তাই "সহায়কভাবে "এটি রূপান্তর করা সমস্যাগুলি আড়াল করতে পারে।

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


3

যদি কোনও সমাধান চয়ন করা আপনার পক্ষে সত্যিই গুরুত্বপূর্ণ না হয়, আপনি কেবলমাত্র ব্যবহারকারীকে সিদ্ধান্ত নিতে দিতে পারেন।

আপনার স্ট্রাক্টটি কেবল পঠনযোগ্য মান অবজেক্ট এবং কোনও পদ্ধতি / নির্মাতার দ্বারা তৈরি করা হয়েছে, আপনি ব্যবহারকারীর কাছে থাকা বিকল্পগুলির উপর ভিত্তি করে দুটি ওভারলোড সরবরাহ করতে পারেন:

  • একটি ব্যতিক্রম নিক্ষেপ (পরিধি ছাড়াই আর্গুমেন্ট)
  • সীমাবদ্ধতায় মান রূপান্তর করুন

এছাড়াও ব্যবহারকারীর আপনার অন্য পদ্ধতিতে পাস করার জন্য কোনও অবৈধ কাঠামো থাকতে দেবেন না, এটি তৈরির সময়েই করুন।

সম্পাদনা: মন্তব্যের উপর ভিত্তি করে, আমি ধরে নিচ্ছি আপনি সি # ব্যবহার করছেন।


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

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

2
@ সোনমান: হ্যাঁ, একই যুক্তির ধরণের সাথে কোনও নির্মাণকারীর ওভারলোড করা কঠিন হবে, তবে দুটি স্থিতিশীল পদ্ধতি এবং একটি প্রাইভেট কনস্ট্রাক্টর থাকা খুব কঠিন হবে না।
wchargin

1
@ কে.গকিনিস: ব্যতিক্রমী ছোঁড়া নির্মাণকারীটির উদ্দেশ্য "অ্যাপ্লিকেশনটি মারা যায় তা নিশ্চিত করে না" - সর্বোপরি, ক্লায়েন্ট সর্বদা catchআপনার ব্যতিক্রম করতে পারে । অন্যরা যেমন বলেছে, এটি ক্লায়েন্টের ইচ্ছা থাকলে নিজেকে সীমাবদ্ধ রাখার অনুমতি দেয় । আপনি সত্যিকার অর্থে কোনও কিছুর অবতারণা করছেন না।
wchargin

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

0

এটি নির্ভর করে যদি ইনপুটটি কোনও ইউআই এর মাধ্যমে সরাসরি কোনও ব্যবহারকারীর কাছ থেকে আসে বা এটি সিস্টেম থেকে আসে।

একটি ইউআই মাধ্যমে ইনপুট

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

  • ব্যবহারকারীকে ত্রুটি সম্পর্কে সতর্ক করুন এবং এগিয়ে যাওয়ার আগে ব্যবহারকারীকে এটি ঠিক করতে দিন (সর্বাধিক সাধারণ)
  • স্বয়ংক্রিয়ভাবে বৈধ পরিসরে রূপান্তর করুন (যদি সম্ভব হয়) তবে ব্যবহারকারীকে পরিবর্তনের বিষয়ে সতর্ক করুন এবং এগিয়ে যাওয়ার আগে ব্যবহারকারীকে যাচাই করার অনুমতি দিন।
  • নিঃশব্দে বৈধ পরিসরে রূপান্তর করুন এবং এগিয়ে যান।

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

সর্বাধিক গুরুত্বপূর্ণ, আপনার যদি বিবেচনা করা উচিত ইনপুট সংশোধন করা এমনকি ব্যবহারকারীর জন্য কোনও উপকার করে। কোনও ব্যবহারকারী কেন অবৈধ তথ্য প্রবেশ করবে? কেউ কীভাবে বানান ত্রুটি করতে পারে তা দেখতে সহজ, তবে কেন কেউ -185 এর দ্রাঘিমাংশে প্রবেশ করবে? যদি ব্যবহারকারী সত্যিই +175 বোঝায় তবে তারা সম্ভবত +175 টাইপ করেছেন। আমি মনে করি এটি সম্ভবত একটি অবৈধ দ্রাঘিমাংশ হ'ল একটি টাইপিং ত্রুটি, এবং ব্যবহারকারীর অর্থ -85 বা অন্য কোনও কিছু। এক্ষেত্রে নিঃশব্দে রূপান্তর করা খারাপ এবং অপ্রয়োজনীয় । আপনার অ্যাপ্লিকেশনটির জন্য সর্বাধিক ব্যবহারকারীর বান্ধব পদ্ধতিটি হ'ল ব্যবহারকারীকে অবৈধ মান সম্পর্কে সতর্ক করা এবং ব্যবহারকারীর নিজেরাই এটি সংশোধন করা উচিত।

কোনও এপিআইয়ের মাধ্যমে ইনপুট দিন

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


0

আপনি একটি ব্যতিক্রম নিক্ষেপ করা উচিত।

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

সীমা ছাড়াই মানগুলির জন্য ব্যতিক্রম ছুঁড়ে ফেলা ভাল।


-1

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

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

বিটিডাব্লু, আমি এখানে জো ডাফির প্রস্তাবিত ত্রুটি মডেলটি সত্যিই পছন্দ করি ।


আপনি কীভাবে ব্যবহারকারীর ইনপুট জন্য সংকলন সময় ত্রুটি সরবরাহ করবেন?
জ্যাকসবি

@ জ্যাকক্সবি যদি প্রকৃত মান সীমাটির মধ্যেই থাকে তবে নির্ধারিত ব্যবহারকারী সন্নিবেশের পরে সীমাতে থাকা সন্ধান করা না হলে সংকলক একটি ত্রুটি জারি করবে ।
গুলশান

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

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

সুতরাং ... আপনাকে একটি নতুন শ্রেণি তৈরি করতে হবে যাতে ইনপুট এবং বৈধতা রয়েছে। অ্যাননড যখন আপনি কাঁচা ইনপুটগুলি থেকে ক্লাস অবজেক্টটি নির্মাণ করেন, তখন কী ঘটে? একটি ব্যতিক্রম নিক্ষেপ? চুপচাপ পাস? আপনি কেবল সমস্যাটি সরান।
djechlin

-1

ডিফল্ট একটি ব্যতিক্রম নিক্ষেপ করা উচিত। আপনি strict=falseপতাকাটির উপর ভিত্তি করে জোর করে এমন কোনও বিকল্পের অনুমতি দিতে ও করতেও পারেন , যেখানে অবশ্যই strict=trueডিফল্ট। এটি মোটামুটি সাধারণ:


এটি কোনও লাভের জন্য কোডটিকে জটিল করে তোলে।
জ্যাকবিবি

@ জ্যাকউসবি ডিফল্টরূপে ব্যতিক্রম নিক্ষেপ করছেন, বা অনুমতি দিচ্ছেন strict=false?
djechlin

@ জ্যাককসবি আমি এমন এপিআইয়ের কয়েকটি উদাহরণ যুক্ত করেছি যা কঠোর এবং লেনেন্ট মোডগুলিকে সমর্থন করে, দয়া করে একবার দেখুন।
djechlin

-2

আমার পক্ষে সর্বোত্তম অনুশীলন হ'ল কখনও ব্যবহারকারী ইনপুট পরিবর্তন করা। আমি সাধারণত যে পদ্ধতি গ্রহণ করি তা হ'ল কার্যকরকরণ থেকে বৈধতা আলাদা করা।

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

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