যখনই একটি অনিয়ন্ত্রিত ব্যতিক্রম বা সংকেতের কারণে একটি অপ্রত্যাশিত প্রস্থান ঘটে তখনই একটি Android অ্যাপ ক্র্যাশ হয়ে যায়। জাভা বা কোটলিন ব্যবহার করে লেখা একটি অ্যাপ ক্র্যাশ হয়ে যায় যদি এটি Throwable ক্লাস দ্বারা উপস্থাপিত একটি আন-হ্যান্ডেল করা ব্যতিক্রম ছুড়ে দেয়। একটি অ্যাপ যা মেশিন কোড ব্যবহার করে লেখা হয় বা C++ ক্র্যাশ হয়ে যায় যদি কোনো আন-হ্যান্ডেল সিগন্যাল থাকে, যেমন SIGSEGV , এটি কার্যকর করার সময়।
যখন একটি অ্যাপ ক্র্যাশ হয়, তখন Android অ্যাপটির প্রক্রিয়া বন্ধ করে দেয় এবং ব্যবহারকারীকে জানাতে একটি ডায়ালগ প্রদর্শন করে যে অ্যাপটি বন্ধ হয়ে গেছে, যেমন চিত্র 1-এ দেখানো হয়েছে।
চিত্র 1. একটি অ্যান্ড্রয়েড ডিভাইসে একটি অ্যাপ ক্র্যাশ
একটি অ্যাপ ক্র্যাশ হওয়ার জন্য অগ্রভাগে চলার প্রয়োজন নেই। যেকোন অ্যাপ কম্পোনেন্ট, এমনকি ব্রডকাস্ট রিসিভার বা কন্টেন্ট প্রোভাইডারের মতো উপাদান যা ব্যাকগ্রাউন্ডে চলছে, একটি অ্যাপ ক্র্যাশ হতে পারে। এই ক্র্যাশগুলি প্রায়শই ব্যবহারকারীদের জন্য বিভ্রান্তিকর কারণ তারা আপনার অ্যাপের সাথে সক্রিয়ভাবে জড়িত ছিল না।
আপনার অ্যাপ ক্র্যাশের সম্মুখীন হলে, আপনি এই পৃষ্ঠার নির্দেশিকা ব্যবহার করে সমস্যাটি নির্ণয় করতে এবং সমাধান করতে পারেন।
সমস্যাটি সনাক্ত করুন
আপনি সবসময় জানেন না যে আপনার ব্যবহারকারীরা যখন আপনার অ্যাপ ব্যবহার করে তখন তারা ক্র্যাশের সম্মুখীন হয়। আপনি যদি ইতিমধ্যেই আপনার অ্যাপ প্রকাশ করে থাকেন, তাহলে আপনি আপনার অ্যাপের ক্র্যাশ রেট দেখতে Android ভাইটাল ব্যবহার করতে পারেন।
অ্যান্ড্রয়েড গুরুত্বপূর্ণ
অ্যান্ড্রয়েড ভাইটাল আপনাকে আপনার অ্যাপের ক্র্যাশ রেট নিরীক্ষণ এবং উন্নত করতে সাহায্য করতে পারে। অ্যান্ড্রয়েড ভাইটাল বিভিন্ন ক্র্যাশ রেট পরিমাপ করে:
- ক্র্যাশ রেট: আপনার দৈনিক সক্রিয় ব্যবহারকারীদের শতাংশ যারা যেকোনো ধরনের ক্র্যাশের সম্মুখীন হয়েছে।
ব্যবহারকারী-অনুভূত ক্র্যাশ রেট: আপনার দৈনিক সক্রিয় ব্যবহারকারীদের শতকরা শতাংশ যারা আপনার অ্যাপটি সক্রিয়ভাবে ব্যবহার করার সময় কমপক্ষে একটি ক্র্যাশের সম্মুখীন হয়েছে (একটি ব্যবহারকারী-অনুভূত ক্র্যাশ)। একটি অ্যাপ সক্রিয় ব্যবহারে বিবেচিত হয় যদি এটি কোনো কার্যকলাপ প্রদর্শন করে বা কোনো ফোরগ্রাউন্ড পরিষেবা সম্পাদন করে।
একাধিক ক্র্যাশ রেট: আপনার দৈনিক সক্রিয় ব্যবহারকারীদের শতাংশ যারা কমপক্ষে দুটি ক্র্যাশের সম্মুখীন হয়েছে৷
একজন দৈনিক সক্রিয় ব্যবহারকারী একজন অনন্য ব্যবহারকারী যিনি আপনার অ্যাপটি একক ডিভাইসে একটি দিনে ব্যবহার করেন, সম্ভাব্য একাধিক সেশনে। যদি একজন ব্যবহারকারী এক দিনে একাধিক ডিভাইসে আপনার অ্যাপ ব্যবহার করেন, প্রতিটি ডিভাইস সেই দিনের জন্য সক্রিয় ব্যবহারকারীর সংখ্যায় অবদান রাখবে। যদি একাধিক ব্যবহারকারী এক দিনে একই ডিভাইস ব্যবহার করেন তবে এটি একজন সক্রিয় ব্যবহারকারী হিসাবে গণনা করা হবে।
ব্যবহারকারী-অনুভূত ক্র্যাশ রেট হল একটি মূল অত্যাবশ্যক যার অর্থ এটি Google Play-তে আপনার অ্যাপের আবিষ্কারযোগ্যতাকে প্রভাবিত করে। এটি গুরুত্বপূর্ণ কারণ এটির ক্র্যাশগুলি সর্বদাই ঘটে যখন ব্যবহারকারী অ্যাপের সাথে জড়িত থাকে, যার ফলে সবচেয়ে বেশি ব্যাঘাত ঘটে।
Play এই মেট্রিকে দুটি খারাপ আচরণের থ্রেশহোল্ড সংজ্ঞায়িত করেছে:
- সামগ্রিকভাবে খারাপ আচরণের থ্রেশহোল্ড: দৈনিক সক্রিয় ব্যবহারকারীদের অন্তত 1.09% সমস্ত ডিভাইস মডেল জুড়ে ব্যবহারকারী-অনুভূত ক্র্যাশের সম্মুখীন হন।
- প্রতি-ডিভাইস খারাপ আচরণের থ্রেশহোল্ড: দৈনিক সক্রিয় ব্যবহারকারীদের অন্তত 8% একটি একক ডিভাইস মডেলের জন্য ব্যবহারকারী-অনুভূত ক্র্যাশের সম্মুখীন হয়।
যদি আপনার অ্যাপটি সামগ্রিক খারাপ আচরণের থ্রেশহোল্ড অতিক্রম করে, তবে এটি সমস্ত ডিভাইসে কম আবিষ্কারযোগ্য হতে পারে। যদি আপনার অ্যাপটি কিছু ডিভাইসে প্রতি-ডিভাইস খারাপ আচরণের থ্রেশহোল্ড অতিক্রম করে, তাহলে সেই ডিভাইসগুলিতে এটি কম খুঁজে পাওয়া যাবে এবং আপনার স্টোরের তালিকায় একটি সতর্কতা দেখানো হতে পারে।
যখন আপনার অ্যাপ অতিরিক্ত ক্র্যাশ দেখায় তখন Android ভাইটাল আপনাকে প্লে কনসোলের মাধ্যমে সতর্ক করতে পারে।
Google Play কীভাবে Android গুরুত্বপূর্ণ ডেটা সংগ্রহ করে সে সম্পর্কে তথ্যের জন্য, Play Console ডকুমেন্টেশন দেখুন।
ক্র্যাশগুলি নির্ণয় করুন
একবার আপনি শনাক্ত করেছেন যে আপনার অ্যাপ ক্র্যাশ রিপোর্ট করছে, পরবর্তী ধাপ হল সেগুলি নির্ণয় করা। ক্র্যাশ সমাধান করা কঠিন হতে পারে। যাইহোক, যদি আপনি ক্র্যাশের মূল কারণ সনাক্ত করতে পারেন, তাহলে সম্ভবত আপনি এটির একটি সমাধান খুঁজে পেতে পারেন।
এমন অনেক পরিস্থিতি রয়েছে যা আপনার অ্যাপে ক্র্যাশ হতে পারে। কিছু কারণ সুস্পষ্ট, যেমন একটি নাল মান বা খালি স্ট্রিং পরীক্ষা করা, কিন্তু অন্যগুলি আরও সূক্ষ্ম, যেমন একটি API-তে অবৈধ আর্গুমেন্ট পাস করা বা এমনকি জটিল মাল্টিথ্রেডেড ইন্টারঅ্যাকশন।
অ্যান্ড্রয়েডে ক্র্যাশগুলি একটি স্ট্যাক ট্রেস তৈরি করে, যা ক্র্যাশ হওয়ার মুহুর্ত পর্যন্ত আপনার প্রোগ্রামে কল করা নেস্টেড ফাংশনগুলির ক্রমটির একটি স্ন্যাপশট। আপনি অ্যান্ড্রয়েড ভাইটালে ক্র্যাশ স্ট্যাকের ট্রেস দেখতে পারেন।
কিভাবে একটি স্ট্যাক ট্রেস পড়তে
ক্র্যাশ ঠিক করার প্রথম ধাপ হল সেই জায়গাটি চিহ্নিত করা যেখানে এটি ঘটে। আপনি যদি Play Console বা logcat টুলের আউটপুট ব্যবহার করেন তাহলে রিপোর্টের বিবরণে উপলব্ধ স্ট্যাক ট্রেস ব্যবহার করতে পারেন। যদি আপনার কাছে একটি স্ট্যাক ট্রেস উপলব্ধ না থাকে, তাহলে আপনাকে স্থানীয়ভাবে ক্র্যাশটি পুনরুত্পাদন করতে হবে, হয় অ্যাপটি ম্যানুয়ালি পরীক্ষা করে বা প্রভাবিত ব্যবহারকারীদের সাথে যোগাযোগ করে, এবং লগক্যাট ব্যবহার করার সময় এটি পুনরুত্পাদন করুন৷
নিম্নলিখিত ট্রেসটি জাভা প্রোগ্রামিং ভাষা ব্যবহার করে লেখা একটি অ্যাপে ক্র্যাশের একটি উদাহরণ দেখায়:
--------- beginning of crash
AndroidRuntime: FATAL EXCEPTION: main
Process: com.android.developer.crashsample, PID: 3686
java.lang.NullPointerException: crash sample
at com.android.developer.crashsample.MainActivity$1.onClick(MainActivity.java:27)
at android.view.View.performClick(View.java:6134)
at android.view.View$PerformClick.run(View.java:23965)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:156)
at android.app.ActivityThread.main(ActivityThread.java:6440)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:746)
--------- beginning of system
একটি স্ট্যাক ট্রেস দুটি তথ্য দেখায় যা ক্র্যাশ ডিবাগ করার জন্য গুরুত্বপূর্ণ:
- ব্যতিক্রম নিক্ষেপের ধরন।
- কোডের বিভাগ যেখানে ব্যতিক্রম নিক্ষেপ করা হয়।
ছুঁড়ে দেওয়া ব্যতিক্রমের ধরনটি সাধারণত কী ভুল হয়েছে তার একটি খুব শক্তিশালী ইঙ্গিত। এটি একটি IOException , একটি OutOfMemoryError , বা অন্য কিছু কিনা তা দেখুন এবং ব্যতিক্রম ক্লাস সম্পর্কে ডকুমেন্টেশন খুঁজুন।
সোর্স ফাইলের ক্লাস, পদ্ধতি, ফাইল এবং লাইন নম্বর যেখানে ব্যতিক্রমটি নিক্ষেপ করা হয়েছে স্ট্যাক ট্রেসের দ্বিতীয় লাইনে দেখানো হয়েছে। কল করা প্রতিটি ফাংশনের জন্য, অন্য একটি লাইন পূর্ববর্তী কল সাইট দেখায় (একটি স্ট্যাক ফ্রেম বলা হয়)। স্ট্যাকের উপরে উঠে কোডটি পরীক্ষা করে, আপনি এমন একটি জায়গা খুঁজে পেতে পারেন যা একটি ভুল মান অতিক্রম করছে। যদি আপনার কোড স্ট্যাক ট্রেসে উপস্থিত না হয়, তাহলে সম্ভবত কোথাও, আপনি একটি অসিঙ্ক্রোনাস অপারেশনে একটি অবৈধ প্যারামিটার পাস করেছেন৷ আপনি প্রায়শই স্ট্যাক ট্রেসের প্রতিটি লাইন পরীক্ষা করে, আপনার ব্যবহার করা যেকোন API ক্লাসগুলি খুঁজে বের করে এবং আপনি পাস করা প্যারামিটারগুলি সঠিক ছিল তা নিশ্চিত করে এবং আপনি অনুমোদিত জায়গা থেকে এটিকে কল করেছেন তা নিশ্চিত করে কী ঘটেছে তা বের করতে পারেন।
C এবং C++ কোড সহ অ্যাপ্লিকেশনগুলির জন্য স্ট্যাক ট্রেসগুলি একইভাবে কাজ করে।
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/foo/bar:10/123.456/78910:user/release-keys'
ABI: 'arm64'
Timestamp: 2020-02-16 11:16:31+0100
pid: 8288, tid: 8288, name: com.example.testapp >>> com.example.testapp <<<
uid: 1010332
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Cause: null pointer dereference
x0 0000007da81396c0 x1 0000007fc91522d4 x2 0000000000000001 x3 000000000000206e
x4 0000007da8087000 x5 0000007fc9152310 x6 0000007d209c6c68 x7 0000007da8087000
x8 0000000000000000 x9 0000007cba01b660 x10 0000000000430000 x11 0000007d80000000
x12 0000000000000060 x13 0000000023fafc10 x14 0000000000000006 x15 ffffffffffffffff
x16 0000007cba01b618 x17 0000007da44c88c0 x18 0000007da943c000 x19 0000007da8087000
x20 0000000000000000 x21 0000007da8087000 x22 0000007fc9152540 x23 0000007d17982d6b
x24 0000000000000004 x25 0000007da823c020 x26 0000007da80870b0 x27 0000000000000001
x28 0000007fc91522d0 x29 0000007fc91522a0
sp 0000007fc9152290 lr 0000007d22d4e354 pc 0000007cba01b640
backtrace:
#00 pc 0000000000042f89 /data/app/com.example.testapp/lib/arm64/libexample.so (com::example::Crasher::crash() const)
#01 pc 0000000000000640 /data/app/com.example.testapp/lib/arm64/libexample.so (com::example::runCrashThread())
#02 pc 0000000000065a3b /system/lib/libc.so (__pthread_start(void*))
#03 pc 000000000001e4fd /system/lib/libc.so (__start_thread)
আপনি যদি নেটিভ স্ট্যাক ট্রেসে ক্লাস এবং ফাংশন-স্তরের তথ্য দেখতে না পান, তাহলে আপনাকে একটি নেটিভ ডিবাগ সিম্বল ফাইল তৈরি করে Google Play কনসোলে আপলোড করতে হতে পারে। আরও তথ্যের জন্য, Deobfuscate ক্র্যাশ স্ট্যাক ট্রেস দেখুন। নেটিভ ক্র্যাশ সম্পর্কে সাধারণ তথ্যের জন্য, নেটিভ ক্র্যাশ নির্ণয় দেখুন।
একটি ক্র্যাশ পুনরুত্পাদন জন্য টিপস
এটা সম্ভব যে আপনি শুধুমাত্র একটি এমুলেটর শুরু করে বা আপনার কম্পিউটারের সাথে আপনার ডিভাইসটি সংযুক্ত করে সমস্যাটি পুরোপুরি পুনরুত্পাদন করতে পারবেন না। ডেভেলপমেন্ট এনভায়রনমেন্টে আরও রিসোর্স থাকে, যেমন ব্যান্ডউইথ, মেমরি এবং স্টোরেজ। রিসোর্সের অভাব কি হতে পারে তা নির্ধারণ করতে ব্যতিক্রমের ধরনটি ব্যবহার করুন বা Android এর সংস্করণ, ডিভাইসের ধরন বা আপনার অ্যাপের সংস্করণের মধ্যে একটি সম্পর্ক খুঁজে বের করুন।
মেমরি ত্রুটি
আপনার যদি একটি OutOfMemoryError থাকে, তাহলে আপনি পরীক্ষা করার জন্য কম মেমরি ক্ষমতা সহ একটি এমুলেটর তৈরি করতে পারেন। চিত্র 2 AVD ম্যানেজার সেটিংস দেখায় যেখানে আপনি ডিভাইসে মেমরির পরিমাণ নিয়ন্ত্রণ করতে পারেন।
চিত্র 2. AVD ম্যানেজারে মেমরি সেটিং
নেটওয়ার্কিং ব্যতিক্রম
যেহেতু ব্যবহারকারীরা প্রায়শই মোবাইল বা ওয়াইফাই নেটওয়ার্ক কভারেজের মধ্যে এবং বাইরে চলে যান, একটি অ্যাপ্লিকেশন নেটওয়ার্কে ব্যতিক্রমগুলিকে সাধারণত ত্রুটি হিসাবে বিবেচনা করা উচিত নয়, বরং অপ্রত্যাশিতভাবে ঘটে যাওয়া স্বাভাবিক অপারেটিং অবস্থা হিসাবে বিবেচনা করা উচিত।
আপনার যদি একটি নেটওয়ার্ক ব্যতিক্রম পুনরুত্পাদন করতে হয়, যেমন একটি UnknownHostException , তাহলে আপনার অ্যাপ্লিকেশন নেটওয়ার্ক ব্যবহার করার চেষ্টা করার সময় বিমান মোড চালু করার চেষ্টা করুন।
আরেকটি বিকল্প হল একটি নেটওয়ার্ক গতি এমুলেশন এবং/অথবা একটি নেটওয়ার্ক বিলম্ব নির্বাচন করে এমুলেটরে নেটওয়ার্কের গুণমান কমানো। আপনি AVD ম্যানেজারে স্পিড এবং লেটেন্সি সেটিংস ব্যবহার করতে পারেন, অথবা আপনি -netdelay এবং -netspeed ফ্ল্যাগগুলির সাথে এমুলেটর শুরু করতে পারেন, যেমনটি নিম্নলিখিত কমান্ড-লাইন উদাহরণে দেখানো হয়েছে:
emulator -avd [your-avd-image] -netdelay 20000 -netspeed gsm
এই উদাহরণটি সমস্ত নেটওয়ার্ক অনুরোধে 20 সেকেন্ডের বিলম্ব এবং 14.4 Kbps এর আপলোড এবং ডাউনলোড গতি সেট করে। এমুলেটরের জন্য কমান্ড-লাইন বিকল্প সম্পর্কে আরও তথ্যের জন্য, কমান্ড লাইন থেকে এমুলেটর শুরু করুন দেখুন।
লগক্যাট দিয়ে পড়া
একবার আপনি ক্র্যাশ পুনরুত্পাদন করতে সক্ষম হয়ে গেলে, আপনি আরও তথ্য পেতে logcat মতো একটি টুল ব্যবহার করতে পারেন।
লগক্যাট আউটপুট আপনাকে দেখাবে যে আপনি সিস্টেমের অন্যান্য লগ বার্তাগুলি মুদ্রণ করেছেন। আপনি যে অতিরিক্ত Log স্টেটমেন্ট যোগ করেছেন তা বন্ধ করতে ভুলবেন না কারণ সেগুলি প্রিন্ট করলে আপনার অ্যাপ চলাকালীন CPU এবং ব্যাটারি নষ্ট হয়।
নাল পয়েন্টার ব্যতিক্রম দ্বারা সৃষ্ট ক্র্যাশ প্রতিরোধ করুন
নাল পয়েন্টার ব্যতিক্রমগুলি (রানটাইম ত্রুটি টাইপ NullPointerException দ্বারা চিহ্নিত) ঘটে যখন আপনি নাল কোন বস্তু অ্যাক্সেস করার চেষ্টা করছেন, সাধারণত এটির পদ্ধতিগুলি ব্যবহার করে বা এর সদস্যদের অ্যাক্সেস করে৷ Google Play-তে অ্যাপ ক্র্যাশের সবচেয়ে বড় কারণ হল নাল পয়েন্টার ব্যতিক্রম। null এর উদ্দেশ্য হল বস্তুটি অনুপস্থিত তা বোঝানো - উদাহরণস্বরূপ, এটি এখনও তৈরি বা বরাদ্দ করা হয়নি। নাল পয়েন্টার ব্যতিক্রমগুলি এড়াতে, আপনাকে নিশ্চিত করতে হবে যে আপনি যে অবজেক্টের রেফারেন্সগুলির সাথে কাজ করছেন সেগুলিতে কল করার পদ্ধতিগুলি বা তাদের সদস্যদের অ্যাক্সেস করার চেষ্টা করার আগে অ-নাল। যদি অবজেক্টের রেফারেন্স নাল থাকে, তাহলে এই কেসটি ভালভাবে পরিচালনা করুন (উদাহরণস্বরূপ, অবজেক্ট রেফারেন্সে কোনও অপারেশন করার আগে একটি পদ্ধতি থেকে প্রস্থান করুন এবং একটি ডিবাগ লগে তথ্য লিখুন)।
যেহেতু আপনি কল করা প্রতিটি পদ্ধতির প্রতিটি প্যারামিটারের জন্য নাল চেক করতে চান না, আপনি শূন্যতা বোঝাতে IDE বা বস্তুর প্রকারের উপর নির্ভর করতে পারেন।
জাভা প্রোগ্রামিং ভাষা
নিম্নলিখিত বিভাগগুলি জাভা প্রোগ্রামিং ভাষার ক্ষেত্রে প্রযোজ্য।
সময় সতর্কতা কম্পাইল
আপনার পদ্ধতির পরামিতি টীকা করুন এবং IDE থেকে কম্পাইল সময় সতর্কতা পেতে @Nullable এবং @NonNull এর সাথে মান দিন। এই সতর্কতাগুলি আপনাকে একটি বাতিলযোগ্য বস্তুর আশা করতে অনুরোধ করে:
এই নাল চেক বস্তুর জন্য যে আপনি জানেন নাল হতে পারে. একটি @NonNull অবজেক্টে একটি ব্যতিক্রম হল আপনার কোডের একটি ত্রুটির ইঙ্গিত যা সমাধান করা দরকার।
সময় ত্রুটি কম্পাইল
কারণ শূন্যতা অর্থপূর্ণ হওয়া উচিত, আপনি যে ধরনের ব্যবহার করেন তাতে আপনি এটি এমবেড করতে পারেন যাতে নাল-এর জন্য একটি কম্পাইল টাইম চেক থাকে। আপনি যদি জানেন যে একটি বস্তু নাল হতে পারে এবং সেই শূন্যতা পরিচালনা করা উচিত, আপনি এটিকে Optional মত একটি বস্তুতে মোড়ানো করতে পারেন। আপনার সর্বদা এমন ধরনের পছন্দ করা উচিত যা শূন্যতা প্রকাশ করে।
কোটলিন
কোটলিনে, শূন্যতা টাইপ সিস্টেমের অংশ। উদাহরণস্বরূপ, একটি ভেরিয়েবলকে শুরু থেকেই বাতিলযোগ্য বা নন-নালবল হিসাবে ঘোষণা করতে হবে। শূন্য প্রকারগুলি একটি দ্বারা চিহ্নিত করা হয় ? :
// non-null
var s: String = "Hello"
// null
var s: String? = "Hello"
অ-শূন্য ভেরিয়েবলকে একটি নাল মান নির্ধারণ করা যায় না এবং নালযোগ্য ভেরিয়েবলগুলি অ-নাল হিসাবে ব্যবহার করার আগে নালযোগ্যতার জন্য পরীক্ষা করা দরকার।
আপনি যদি শূন্যের জন্য স্পষ্টভাবে পরীক্ষা করতে না চান, তাহলে আপনি ব্যবহার করতে পারেন ?. নিরাপদ কল অপারেটর:
val length: Int? = string?.length // length is a nullable int
// if string is null, then length is null
একটি সর্বোত্তম অনুশীলন হিসাবে, নিশ্চিত করুন যে আপনি একটি বাতিলযোগ্য বস্তুর জন্য নাল কেসটি সম্বোধন করেছেন বা আপনার অ্যাপ অপ্রত্যাশিত অবস্থায় যেতে পারে। NullPointerException এর সাথে আপনার অ্যাপ্লিকেশনটি আর ক্র্যাশ না হলে, আপনি জানবেন না যে এই ত্রুটিগুলি বিদ্যমান।
নাল চেক করার কিছু উপায় নিচে দেওয়া হল:
ifচেক করেval length = if(string != null) string.length else 0স্মার্ট-কাস্ট এবং নাল চেকের কারণে, কোটলিন কম্পাইলার জানে যে স্ট্রিং মানটি নন-নাল তাই এটি আপনাকে নিরাপদ কল অপারেটরের প্রয়োজন ছাড়াই সরাসরি রেফারেন্স ব্যবহার করার অনুমতি দেয়।
এই অপারেটর আপনাকে "যদি অবজেক্টটি নন-নাল হয়, বস্তুটি ফেরত দিন; অন্যথায়, অন্য কিছু ফেরত দিন"।
val length = string?.length ?: 0
আপনি এখনও Kotlin এ একটি NullPointerException পেতে পারেন। নিম্নলিখিত সবচেয়ে সাধারণ পরিস্থিতি:
- যখন আপনি স্পষ্টভাবে একটি
NullPointerExceptionনিক্ষেপ করছেন। - আপনি যখন শূন্য দাবী ব্যবহার করছেন
!!অপারেটর এই অপারেটর যেকোনো মানকে একটি নন-নাল টাইপে রূপান্তর করে, যদি মানটি নাল থাকে তাহলেNullPointerExceptionনিক্ষেপ করে। - একটি প্ল্যাটফর্ম প্রকারের একটি নাল রেফারেন্স অ্যাক্সেস করার সময়।
প্ল্যাটফর্ম প্রকার
প্ল্যাটফর্মের ধরন হল জাভা থেকে আসা বস্তুর ঘোষণা। এই ধরনের বিশেষভাবে চিকিত্সা করা হয় ; নাল চেকগুলি প্রয়োগ করা হয় না, তাই নন-নাল গ্যারান্টি জাভাতে একই রকম। আপনি যখন একটি প্ল্যাটফর্ম টাইপ রেফারেন্স অ্যাক্সেস করেন, তখন কোটলিন কম্পাইল টাইম ত্রুটি তৈরি করে না কিন্তু এই রেফারেন্সগুলি রানটাইম ত্রুটির কারণ হতে পারে। কোটলিন ডকুমেন্টেশন থেকে নিম্নলিখিত উদাহরণ দেখুন:
val list = ArrayList<String>() // non-null (constructor result) list.add("Item")
val size = list.size // non-null (primitive int) val item = list[0] // platform
type inferred (ordinary Java object) item.substring(1) // allowed, may throw an
// exception if item == null
Kotlin টাইপ ইনফারেন্সের উপর নির্ভর করে যখন একটি প্ল্যাটফর্ম মান একটি Kotlin ভেরিয়েবলের জন্য বরাদ্দ করা হয়, অথবা আপনি কি ধরনের আশা করতে পারেন তা নির্ধারণ করতে পারেন। জাভা থেকে আসা একটি রেফারেন্সের সঠিক শূন্যতার অবস্থা নিশ্চিত করার সর্বোত্তম উপায় হল আপনার জাভা কোডে নালবিলিটি টীকা (উদাহরণস্বরূপ, @Nullable ) ব্যবহার করা। কোটলিন কম্পাইলার এই রেফারেন্সগুলিকে প্রকৃত বাতিলযোগ্য বা অ-নূলযোগ্য প্রকার হিসাবে উপস্থাপন করবে, প্ল্যাটফর্মের প্রকার হিসাবে নয়।
জাভা জেটপ্যাক এপিআইগুলিকে প্রয়োজন অনুসারে @Nullable বা @NonNull দিয়ে টীকা করা হয়েছে এবং Android 11 SDK- তেও একই পদ্ধতি নেওয়া হয়েছে। এই SDK থেকে আগত প্রকারগুলি, যেগুলি Kotlin-এ ব্যবহৃত হয়, সঠিক নালযোগ্য বা অ-নূলযোগ্য প্রকার হিসাবে উপস্থাপন করা হবে৷
কোটলিনের টাইপ সিস্টেমের কারণে, আমরা দেখেছি অ্যাপগুলির NullPointerException ক্র্যাশগুলির একটি বড় হ্রাস রয়েছে৷ উদাহরণস্বরূপ, গুগল হোম অ্যাপটি কোটলিনে নতুন বৈশিষ্ট্য বিকাশের স্থানান্তরিত হওয়ার বছরটিতে নাল পয়েন্টার ব্যতিক্রমগুলির কারণে ক্র্যাশে 30% হ্রাস পেয়েছে।