জাভা.এলং.এররর কখন ধরবেন?

Question

কোন পরিস্থিতিতে একটি ধরা উচিত java.lang.Error একটি আবেদন ?

Comments

আরও দেখুন stackoverflow.com/questions/2679330/...

— Raedwald

Answer 1

সাধারণত, কখনও না।

তবে, কখনও কখনও আপনার নির্দিষ্ট ত্রুটিগুলি ধরতে হবে।

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

আমি কিছু বোকা তৃতীয়-পক্ষের কোডগুলি সাবক্লাস ছুঁড়ে মারতেও দেখেছি Error, সুতরাং আপনার সেগুলিও পরিচালনা করতে হবে।

যাইহোক, আমি নিশ্চিত যে এটি থেকে পুনরুদ্ধার করা সম্ভব নয় OutOfMemoryError।

Comments

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

— মারিও অর্টেগন

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

— স্পেসট্রকার

@ স্পেসট্রিকার: এটি কী মাল্টিথ্রেডেড অ্যাপ্লিকেশনগুলিতে ভাল কাজ করে, বা অন্যান্য থ্রেডে ছোট বরাদ্দ ব্যর্থ হওয়ার কারণে এটির কোনও ঝুঁকি রয়েছে? … সম্ভবতঃ যদি আপনার অ্যারেগুলি বরাদ্দ করার মতো যথেষ্ট ছোট ছিল তবে অন্য কারও জন্য কিছুই রাখেনি।

— পিজেট্রাইল

@PJTraill- এ সম্পর্কে আমি নিশ্চিত নই এর জন্য কিছু বাস্তব বিশ্ব পরিসংখ্যানের নমুনার প্রয়োজন হবে। আমি ভেবেছিলাম আমি এই জাতীয় কোড দেখেছি তবে এটি কোথায় ছিল তা মনে করতে পারছি না।

— স্পেসট্রকার

Answer 2

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

http://pmd.sourceforge.net/rules/strictexception.html

Comments

কখনও না বল না. আমাদের কাছে টেস্টিং কোড রয়েছে যা "মিথ্যা দাবি করে"; তারপরে -E পতাকাটি সেট করা আছে তা নিশ্চিত করতে AssertionError কে ক্যাচ করে। তা ছাড়া ... হ্যাঁ, সম্ভবত কখনও নয় ;-)

— আউটলা প্রোগ্রামার

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

— লেইগ

কখনই না ... যখন আপনার একেবারে প্রয়োজন হয় except কখনও শক্তিশালী শব্দ নয় এবং নিয়মে সর্বদা ব্যতিক্রম থাকে। যদি আপনি কোনও কাঠামো তৈরি করে থাকেন তবে এটি কেবলমাত্র লগইন করার পরেও আপনাকে কিছু ত্রুটিগুলি ধরতে এবং পরিচালনা করতে হবে এমন সম্ভাবনা কম নয়।

— রবিন

ত্রুটিগুলি সম্পর্কে কীভাবে তৃতীয় পক্ষের লাইব্রেরি পদ্ধতি থেকে আগত NoSuchMethodError?

— ha9u63ar

@ ওটলাও প্রোগ্রামার কেবল রেকর্ডের জন্য, একই পরীক্ষা করার জন্য অন্যান্য উপায় রয়েছে:boolean assertionsEnabled = false; assert assertionsEnabled = true;

— shmosel

Answer 3

সাধারণত আপনার সবসময় java.lang.Errorএটি কোনও লগতে ধরা এবং লিখতে হবে বা এটি ব্যবহারকারীর কাছে প্রদর্শন করা উচিত। আমি সহায়তায় কাজ করি এবং প্রতিদিন দেখি যে প্রোগ্রামাররা কোনও প্রোগ্রামে কী ঘটেছিল তা বলতে পারে না।

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

আপনার কেবল java.lang.Errorউচ্চ স্তরে ধরা উচিত ।

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

সর্বাধিক সাধারণ ত্রুটিগুলি OutOfMemoryErrorএবং NoClassDefFoundErrorএটি উভয়ই বেশিরভাগ ক্ষেত্রে রানটাইম সমস্যা।

উদাহরণ স্বরূপ:

int length = Integer.parseInt(xyz);
byte[] buffer = new byte[length];

একটি উত্পাদন করতে পারে OutOfMemoryErrorতবে এটি একটি রানটাইম সমস্যা এবং আপনার প্রোগ্রামটি বন্ধ করার কোনও কারণ নয়।

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

Throwableশীর্ষ স্তরে ধরা এবং একটি সহায়ক ত্রুটি বার্তা উত্পন্ন করার জন্য কেন এটি ভাল ধারণা কেন আমি তার আরও অনেক উদাহরণ দিতে পারি ।

Comments

আমি সঠিকভাবে সতর্কতা দিয়ে ডেমনকে ব্যর্থ করাতে তার ক্ষেত্রে আরও সন্দেহজনক হতে পারি তবে এটি ব্যর্থ jvm তে কিছু ইথেরিয়াল ভূত হিসাবে বেঁচে থাকার সম্ভাবনা থাকতে পারে যেখানে এটি সত্যই বেঁচে আছে এবং কিছু করছে এমন মিথ্যা বাহানা দিতে পারে

— অ্যান্ড্রু নর্মন

OutOfMemoryErrorরানটাইম ত্রুটি নয় যা অ্যাপ্লিকেশনটি এটি থেকে পুনরুদ্ধার করতে পারে তার কোনও গ্যারান্টি নেই। আপনি যদি ভাগ্যবান হন new byte[largeNumber]তবে আপনি OOM এ পেতে পারেন তবে যদি সেই বরাদ্দ OOM এর পক্ষে যথেষ্ট না হয় তবে এটি পরবর্তী লাইনে বা পরবর্তী থ্রেডে ট্রিগার হতে পারে। এটি রানটাইম সমস্যা কারণ lengthঅবিশ্বস্ত ইনপুট থাকলে এটি কল করার আগে বৈধ হওয়া উচিত new byte[]।

— Jeeyoung Kim

NoClassDefFoundErrorযে কোনও জায়গায় ঘটতে পারে , যখন জাভা কোডটি সংকলিত হয় তখন এটি ক্লোজ করা যায় না। যদি আপনার জেডিকে ভুল কনফিগার করা থাকে তবে এটি java.util.*শ্রেণি ব্যবহারের চেষ্টা থেকে ট্রিগার করতে পারে এবং এর বিরুদ্ধে প্রোগ্রাম করা কার্যত অসম্ভব। আপনি যদি বিকল্পভাবে নির্ভরতা সহ অন্তর্ভুক্ত থাকেন তবে আপনার উপস্থিতি আছে ClassLoaderকিনা তা যাচাই করার জন্য আপনার ব্যবহার করা উচিত যা কোনটি ছুঁড়ে ClassNotFoundException।

— Jeeyoung Kim

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

— Jeeyoung Kim

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

— Jeeyoung Kim

Answer 4

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

উদাহরণস্বরূপ, সাধারণত লুপটি হওয়া উচিত:

try {
   while (shouldRun()) {
       doSomething();
   }
}
catch (Throwable t) {
   log(t);
   stop();
   System.exit(1);
}

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

Comments

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

— রায়েডওয়াল্ড

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

— অ্যান্ড্রু নরম্যান

Answer 5

খুবই কদাচিৎ.

আমি থ্রেডের মৃত্যুর কারণ সহ একটি বার্তা জারি করতে এটিএমটিপিতে কেবল একটি থ্রেডের শীর্ষ স্তরে বলতে চাই।

আপনি যদি এমন কোনও ফ্রেমওয়ার্কে থাকেন যা এই ধরণের জিনিস আপনার জন্য করে তবে ফ্রেমওয়ার্কটিতে রেখে দিন।

Answer 6

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

Answer 7

একটি Errorসাধারণত ধরা উচিত নয় , কারণ এটি এমন অস্বাভাবিক অবস্থা নির্দেশ করে যা কখনই ঘটে না ।

Errorশ্রেণীর জন্য জাভা এপিআই স্পেসিফিকেশন থেকে :

একটি Errorএটি একটি সাবক্লাস Throwable যা গুরুতর সমস্যাগুলি নির্দেশ করে যা যুক্তিসঙ্গত প্রয়োগটি ধরার চেষ্টা করা উচিত নয়। এ জাতীয় বেশিরভাগ ত্রুটিগুলি অস্বাভাবিক শর্ত। [...]

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

স্পেসিফিকেশনটিতে যেমন উল্লেখ করা হয়েছে, একটি Errorকেবল এমন পরিস্থিতিতে ফেলে দেওয়া হয় যা সম্ভাবনা থাকে, যখন Errorঘটে থাকে তখন অ্যাপ্লিকেশনটি খুব কম করতে পারে এবং কিছু পরিস্থিতিতে জাভা ভার্চুয়াল মেশিন নিজেই অস্থির অবস্থায় থাকতে পারে (যেমন VirtualMachineError)

যদিও Errorএটি একটি সাবক্লাস Throwableযার অর্থ এটি একটি try-catchধারা দ্বারা ধরা পড়তে পারে তবে এটি সম্ভবত সত্যই প্রয়োজন হয় না, কারণ অ্যাপ্লিকেশনটি অস্বাভাবিক অবস্থায় থাকবে যখন একটিError জেভিএম দ্বারা নিক্ষেপ করা

এছাড়া বিভাগের এই বিষয়ে একটি সংক্ষিপ্ত অধ্যায় 11.5 ব্যতিক্রম শ্রেণীক্রম এর জাভা ল্যাঙ্গুয়েজ স্পেসিফিকেশন, 2nd সংস্করণ ।

Answer 8

আপনি যদি নতুন ইউনিট পরীক্ষার কাঠামো তৈরি করতে যথেষ্ট পাগল হন তবে আপনার পরীক্ষা রানার সম্ভবত java.lang.AssertionError কে ধরতে হবে যে কোনও পরীক্ষার ক্ষেত্রে ফেলে দেওয়া হয়েছে।

অন্যথায়, অন্যান্য উত্তর দেখুন।

Answer 9

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

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

Comments

এটি আসলে একটি নন-ইস্যু কারণ আপনি কেবল এসকে ধরেন নাError ।

— বোম্বে

Answer 10

খুব, খুব কমই।

আমি এটি কেবল একটি খুব নির্দিষ্ট নির্দিষ্ট কেসের জন্য করেছি। উদাহরণস্বরূপ, java.lang.UnsatisectedLinkError নিক্ষিপ্ত হতে পারে যদি দুটি স্বাধীনতা ClassLoader একই ডিএলএল লোড করে। (আমি সম্মত হই যে আমার জেআর একটি ভাগ করা শ্রেণীবদ্ধে স্থানান্তর করা উচিত)

তবে সর্বাধিক সাধারণ ক্ষেত্রে হ'ল ব্যবহারকারী যখন অভিযোগ করতে আসে তখন কী ঘটেছিল তা জানতে আপনার লগিংয়ের প্রয়োজন ছিল। আপনি ব্যবহারকারীকে একটি বার্তা বা একটি পপআপ চান, বরং নীরবে মৃত।

এমনকি সি / সি ++ তে প্রোগ্রামার, তারা একটি ত্রুটি পপ করে এবং কিছু বেরোনোর ​​আগে লোকেরা বুঝতে পারে না (যেমন মেমরির ব্যর্থতা)।

Answer 11

একটি অ্যান্ড্রয়েড অ্যাপ্লিকেশনটিতে আমি একটি java.lang.VerifyError ধরছি । আমি যে লাইব্রেরিটি ব্যবহার করছি সেটি ওএস এবং পুস্তকাগুলির কোড সহ পুরানো সংস্করণযুক্ত ডিভাইসে কাজ করবে না such আমি অবশ্যই রানটাইমে ওএস এর সংস্করণ পরীক্ষা করে ত্রুটিটি এড়াতে পারতাম, তবে:

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

Answer 12

এটি একটি পরীক্ষার পরিবেশে java.lang.AssertionError ধরা বেশ সহজ ...

Comments

আপনি কোন মান যুক্ত করার চেষ্টা করছেন?

— lpapp

বাতিল হওয়া নয় এমন পরীক্ষার স্যুটটির মান যুক্ত করা

— জোনো

Answer 13

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

Answer 14

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

Answer 15

দৃ unit়তা পরীক্ষা করা হয়েছে যে ইউনিট পরীক্ষার মধ্যে ত্রুটি ধরা উপযুক্ত হবে। যদি কেউ দৃser় অক্ষম অক্ষম করে বা অন্যথায় দৃ dele়তা মুছে ফেলা হয় তবে আপনি জানতে চান

Answer 16

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

এটি চলমান কম্পিউটারের উপর নির্ভর করবে, বর্তমান মেমরির অবস্থার উপর নির্ভর করে, তাই আপনার সর্বোত্তম চেষ্টা করার, চেষ্টা করার এবং করার কোনও উপায় নেই। আপনার কেবলমাত্র একটি প্রচুর ফলাফল হবে।

আপনি আপনার কোডের পঠনযোগ্যতাও হ্রাস করবেন।