কল স্ট্যাকের শীর্ষে পৌঁছালে আপনার অ্যাপ্লিকেশন ক্র্যাশ হওয়া থেকে রক্ষা করার জন্য একটি উত্থাপিত ব্যতিক্রম উদ্ধার করা যেতে পারে। রুবিতে, আমরা rescue ব্যবহার করি এর জন্য কীওয়ার্ড।
রুবিতে একটি ব্যতিক্রম উদ্ধার করার সময়, আপনি একটি নির্দিষ্ট ত্রুটির শ্রেণী উল্লেখ করতে পারেন যা থেকে উদ্ধার করা উচিত।
begin
raise 'This exception will be rescued!'
rescue StandardError => e
puts "Rescued: #{e.inspect}"
end
দ্রষ্টব্য :raise ব্যবহার করার সময় একটি ব্যতিক্রম ক্লাস নির্দিষ্ট না করে, রুবি ডিফল্ট হবে RuntimeError .
রেসকিউ করার জন্য একটি ব্যতিক্রম ক্লাস নির্দিষ্ট করার পাশাপাশি, আপনি rescue-এ ব্যতিক্রম ক্লাসের একটি অ্যারে পাস করতে পারেন। কীওয়ার্ড এটি আপনাকে একইভাবে একাধিক ত্রুটির প্রতিক্রিয়া জানাতে অনুমতি দেবে৷
begin
raise 'This exception will be rescued!'
rescue StandardError, AnotherError => e
puts "Rescued: #{e.inspect}"
end
একাধিক rescue ব্লকগুলি বিভিন্ন উপায়ে বিভিন্ন ত্রুটি পরিচালনা করতে ব্যবহার করা যেতে পারে। একটি লাইব্রেরির সাথে কাজ করার সময় এটি কার্যকর হতে পারে যা বিভিন্ন পরিস্থিতিতে বিভিন্ন ব্যতিক্রম তৈরি করে।
begin
raise 'This exception will be rescued!'
rescue StandardError => e
puts "Rescued: #{e.inspect}"
rescue AnotherError => e
puts "Rescued, but with a different block: #{e.inspect}"
end ব্যতিক্রম অনুক্রম
রুবির ব্যতিক্রম শ্রেণিবিন্যাস বিভিন্ন ধরনের ত্রুটির মধ্যে পার্থক্য করার জন্য ব্যবহার করা হয়, যখন আপনাকে তাদের সমস্ত নির্দিষ্ট না করেই ত্রুটিগুলির একটি গোষ্ঠী থেকে উদ্ধার করার ক্ষমতা দেয়৷
যদিও লাইব্রেরিগুলি তাদের নিজস্ব ব্যতিক্রম সাবক্লাসগুলিকে সংজ্ঞায়িত করতে পারে, রুবি 2.5-তে অন্তর্নির্মিত ব্যতিক্রম সাবক্লাসগুলির তালিকাটি এইরকম দেখাচ্ছে:
- NoMemoryError
- ScriptError
- LoadError
- NotImplementedError
- SyntaxError
- SecurityError
- SignalException
- Interrupt
- StandardError (default for `rescue`)
- ArgumentError
- UncaughtThrowError
- EncodingError
- FiberError
- IOError
- EOFError
- IndexError
- KeyError
- StopIteration
- LocalJumpError
- NameError
- NoMethodError
- RangeError
- FloatDomainError
- RegexpError
- RuntimeError (default for `raise`)
- SystemCallError
- Errno::*
- ThreadError
- TypeError
- ZeroDivisionError
- SystemExit
- SystemStackError
- fatal (impossible to rescue)
rescue-এ ব্যতিক্রম ক্লাস বাদ দেওয়ার সময় ব্লক, StandardError অনুমান করা হচ্ছে. কারণ ArgumentError এবং NoMethodError StandardError এর সাবক্লাস , এগুলি ব্লকে ঘটলে থেকে উদ্ধার করা হয়।
ব্যতিক্রম শ্রেণিবিন্যাস কীভাবে কাজ করে তার একটি ভাল উদাহরণ হল SystemCallError , যা একটি নিম্ন-স্তরের প্ল্যাটফর্ম-নির্ভর ব্যতিক্রম শ্রেণী। ফাইল পড়ার বা লেখার সময় এটি প্রায়শই দেখা যায়।
রুবির File.read পদ্ধতিটি একটি ব্যতিক্রম উত্থাপন করবে যদি এটি ফাইলটি পড়তে ব্যর্থ হয়। এটি বিভিন্ন কারণে ঘটতে পারে, যেমন ফাইলটি বিদ্যমান নেই বা প্রোগ্রামটির এটি পড়ার সঠিক অনুমতি নেই।
যেহেতু এই সমস্যাগুলি প্ল্যাটফর্ম-নির্ভর, তাই মেশিনে কি ধরনের অপারেটিং সিস্টেম চলছে তার উপর নির্ভর করে রুবি ভিন্ন ভিন্ন ব্যতিক্রম ঘটাতে পারে। এই ধরনের নিম্ন-স্তরের ত্রুটির জন্য, রুবি Errno::* এর একটি ভিন্ন তালিকা প্রয়োগ করে -প্রতিটি প্ল্যাটফর্মের জন্য ব্যতিক্রম।
এই সমস্ত Errno::* ব্যতিক্রম হল SystemCallError এর সাবক্লাস . যদিও সেগুলি প্ল্যাটফর্ম-নির্দিষ্ট, তবুও সেগুলি একটি rescue এ ব্যবহার করা যেতে পারে SystemCallError থেকে উদ্ধার করে ব্লক করুন .
begin
File.read("does/not/exist")
rescue SystemCallError => e
puts "Rescued: #{e.inspect}"
end গিলে ফেলা ব্যতিক্রমগুলি
সাধারণত, ব্যতিক্রমগুলিকে উদ্ধার করার সময় যতটা সম্ভব নির্দিষ্ট হওয়া ভাল, যাতে অনিচ্ছাকৃতভাবে ব্যতিক্রমগুলি গ্রাস করা রোধ করা যায়।
image = nil
begin
File.read(image.filename)
rescue
puts "File can't be read!"
end
এই উদাহরণে, image পরিবর্তনশীল হল nil , তাই এটি একটি NoMethodError উত্থাপন করে যখন আমরা #filename কল করার চেষ্টা করি এটিতে (NoMethodError: undefined method `filename' for nil:NilClass এর জন্য অনির্ধারিত পদ্ধতি `ফাইলের নাম' ) কারণ প্রতিটি StandardError সাবক্লাস থেকে উদ্ধার করা হয়েছে (NoMethodError সহ ), ব্যতিক্রম গ্রাস করা হয় এবং "ফাইল পড়া যাবে না!"-বার্তা মুদ্রিত হয়। এটি কোডে একটি সম্ভাব্য বাগ লুকিয়ে রাখে।
দ্রষ্টব্য :যদিও এটা সম্ভব, Exception ব্যবহার করে একটি rescue এ সুপারক্লাস ব্লক অত্যন্ত নিরুৎসাহিত করা হয়।
রুবিতে ব্যতিক্রম উত্থাপন বা উদ্ধার সম্পর্কে কোন প্রশ্ন আছে? অনুগ্রহ করে আমাদের @AppSignal এ জানাতে দ্বিধা করবেন না। অবশ্যই, আমরা জানতে চাই যে আপনি এই নিবন্ধটি কীভাবে পছন্দ করেছেন, অথবা আপনার যদি অন্য কোনো বিষয় থাকে যে সম্পর্কে আপনি আরও জানতে চান।