అసాధారణ పరిస్థితి నిర్వహణ

వికీపీడియా నుండి
ఇక్కడికి గెంతు: మార్గసూచీ, వెతుకు

అసాధారణ పరిస్థితి నిర్వహణ అనేది ప్రోగ్రామ్ యొక్క అమలులో సాధారణ క్రమంలో మార్పుకు కారణమయ్యే ప్రత్యేక అసామాన్య పరిస్థితులను నిర్వహించడానికి రూపొందించిన ప్రోగ్రామింగ్ లాంగ్వేజ్ నిర్మాణం లేదా కంప్యూటర్ హార్డ్‌వేర్ యాంత్రిక విధానంగా చెప్పవచ్చు.

అసాధారణ పరిస్థితి నిర్వహణకు ప్రోగ్రామింగ్ లాంగ్వేజ్‌లు వేర్వేరు మద్దతును కలిగి ఉంటాయి (ఇది లోపాల తనిఖీకి విరుద్ధంగా ఉంటుంది, ఇది చెల్లని మార్పులు లేదా ప్రారంభమైన చర్యల వైఫల్య ముగింపు వంటి ప్రతికూల ఆటంకాలకు స్పందనగా కోడ్ చేసిన సాధారణ ప్రోగ్రామ్ అమలు విధానంగా చెప్పవచ్చు.) కొన్ని ప్రోగ్రామింగ్ లాంగ్వేజ్‌ల్లో, చెల్లని ఇన్‌పుట్ డేటాతో సురక్షితంగా పని చేయని ఫంక్షన్‌లు ... లేదా అసాధారణ విలువలకు సమానంగా ఉండే విలువలను అందించే ఫంక్షన్‌లు ఉన్నాయి. ఉదాహరణకు, Cలో, atoi (ASCII నుండి పూర్ణాంకంగా మార్పిడి) ఫంక్షన్ ఒక చెల్లుబాటు అయ్యే విలువలోకి అన్వయించబడని ఏదైనా ఇన్‌పుట్‌కు 0 (సున్నా)ను అందించవచ్చు. ఇటువంటి లాంగ్వేజ్‌ల్లో, ప్రోగ్రామర్ తప్పక లోపాల తనిఖీని (C యొక్క errno వంటి కొన్ని సహాయక గ్లోబల్ వేరేబుల్ ద్వారా) లేదా ఇన్‌పుట్ ధ్రువీకరణ (అయితే సాధారణ వ్యక్తీకరణలను ఉపయోగించి) అమలు చేయాలి.

ఇటువంటి ప్రత్యేక ధ్రువీకరణ మరియు లోపాల తనిఖీ అవసరమయ్యే స్థాయి ఏదైనా ప్రోగ్రామింగ్ ఎన్విరాన్మెంట్‌చే అసాధారణ పరిస్థితి నిర్వహణకు అందించబడే మద్దతుకు విరుద్ధంగా ఉంటుంది. హార్డ్‌వేర్ అసాధారణ పరిస్థితి నిర్వహణ అనేది సాఫ్ట్‌వేర్ ఉపకరణాలచే అందించబడే మద్దతుకు కొంచెం వ్యత్యాసంగా ఉంటుంది, కాని అదే విషయాలు మరియు పరిభాషలు సర్వసాధారణం.

సాధారణంగా, ఒక అసాధారణ పరిస్థితిని ప్రస్తుత అమలు దశను ఒక ముందే ఊహించిన స్థానంలో నిల్వ చేసి, ఒక అసాధారణ పరిస్థితి నిర్వహణ వ్యవస్థ అని పిలిచే ఒక నిర్దిష్ట సబ్‌రొటీన్ అమలు అయ్యేలా చేయడం ద్వారా నిర్వహిస్తారు . సందర్భానుసారంగా, తర్వాత నిర్వహణ వ్యవస్థ భద్రపరిచిన సమాచారాన్ని ఉపయోగించి అమలును యదార్ధ స్థానం నుండి మళ్లీ కొనసాగించవచ్చు. ఉదాహరణకు, ఒక పేజ్ ఫాల్ట్ అనేది సాధారణంగా ప్రోగ్రామ్ మళ్లీ కొనసాగడానికి అనుమతిస్తుంది, అయితే ఒక డివిజెన్ బై జీరో అనేది పారదర్శకంగా పరిష్కరించలేనిది కావచ్చు.

ప్రాసెసింగ్ ప్రకారం, హార్డ్‌వేర్ అంతరాయికాలు అనేవి మళ్లీ కొనసాగించగల అసాధారణ అంశాలు వంటివి, అయితే ఇవి సాధారణంగా వినియోగదారు యొక్క ప్రోగ్రామ్ గమనానికి సంబంధించి ఉండవు.

ఒక రొటీన్‌ను రాసిన వ్యక్తి ప్రకారం, ఒక అసాధారణ పరిస్థితి ఏర్పడేలా చేయడం అనేది ఒక రొటీన్ సజావుగా అమలు కావడం సాధ్యం కాదనే సూచనకు ఒక ఉపయోగకరమైన మార్గంగా చెప్పవచ్చు. ఉదాహరణకు, ఒక ఇన్‌పుట్ అంశం చెల్లుబాటు కానప్పుడు (ఉదా. భాగాహరంలో ఒక సున్నా విభాజకం) లేదా అందుబాటులో లేని ఒక వనరు అవసరమైనప్పుడు (లభ్యతలో లేని ఫైల్ లేదా ఒక హార్డ్ డిస్క్ లోపం). అసాధారణ పరిస్థితులు లేని వ్యవస్థల్లో, రొటీన్‌లు కొన్ని ప్రత్యేక లోప సంకేతాన్ని అందించాల్సిన అవసరం ఉంది. అయితే, ఇది కొన్నిసార్లు సెమీప్రెడికేట్ సమస్యతో క్లిష్టంగా మారవచ్చు, ఈ సందర్భంలో రొటీన్ యొక్క వినియోగదారులు లోపాల విలువల నుండి సాధారణ అవుట్‌పుట్ విలువలను వేరు చేయడానికి అదనపు కోడ్‌ను రాయాల్సి ఉంటుంది.

జావా లేదా .NET వంటి రన్‌టైమ్ ఇంజిన్ ఎన్విరాన్మెంట్‌ల్లో, రన్‌టైమ్ ఇంజిన్‌లకు జోడించిన పరికరాలు ఉన్నాయి మరియు ఒక అసాధారణ పరిస్థితి ఏర్పడిన ప్రతిసారి, అవి అసాధారణ పరిస్థితిని ఏర్పరిచిన సమయంలో మెమరీలో ఉన్న డీబగ్ సమాచారాన్ని రికార్డ్ చేస్తాయి (కాల్ స్టాక్ మరియు హీప్ విలువలు). ఇటువంటి సాధనాలను స్వయంచాలక అసాధారణ పరిస్థితి నిర్వహణ లేదా లోప అవరోధ సాధనాలుగా పిలుస్తారు మరియు ఇవి అసాధారణ పరిస్థితులకు 'ప్రధాన కారణమైన' సమాచారాన్ని అందిస్తాయి.

అసాధారణ పరిస్థితి నిర్వహణ పద్ధతుల విషయంలో సమకాలీన అనువర్తనాలు పలు రూపకల్పన సవాళ్లను ఎదుర్కొంటున్నాయి. ప్రత్యేకంగా ఆధునిక వాణిజ్య స్థాయి అనువర్తనాల్లో, అసాధారణ అంశాలు తరచూ ప్రాసెస్ హద్దులు మరియు మెషీన్ హద్దులను మించిపోతున్నాయి. ఒక శక్తివంతమైన అసాధారణ పరిస్థితి నిర్వహణ పద్ధతి రూపకల్పన అనేది ప్రాసెస్‌లో సాఫ్ట్‌వేర్ విభాగంచే ఆర్థికంగా నిర్వహించలేక విఫలమైన స్థానాన్ని గుర్తించడానికి చెప్పవచ్చు. [1]

అసాధారణ పరిస్థితి భద్రత[మార్చు]

అమలు అవుతున్న సమయంలోని కోడ్‌లోని వైఫల్యాలు చెడు ప్రభావాలు అంటే మెమరీ లీకేజ్, అపక్రమంలో నిల్వ చేయబడిన డేటా, చెల్లని అవుట్‌పుట్ వంటివి ప్రదర్శించకుంటే కోడ్‌లో కొంత భాగం అసాధారణ నిర్వహణకు భద్రత ను కలిగి ఉందని చెప్పవచ్చు. అసాధారణ పరిస్థితి భద్రత కోడ్ అసాధారణ పరిస్థితులు ఏర్పడినప్పుడు కూడా కోడ్‌లో ఉండే స్థిరరాశులను సంతృప్తి పర్చాలి. ఇక్కడ పలు అసాధారణ పరిస్థితి భద్రతా స్థాయిలు ఉన్నాయి:

  1. నో థ్రో గ్యారంటీ అని కూడా పిలిచే వైఫల్య పారదర్శకత : అసాధారణ పరిస్థితుల్లో కూడా కార్యాచరణలు విజయవంతమవుతాయని మరియు అన్ని అవసరాలు సంతృప్తి చెందుతాయని హామీ ఉంటుంది. ఒక అసాధారణ పరిస్థితి ఎదురైతే, ఇది ఒక అసాధారణ పరిస్థితిని ముందుకు కొనసాగించదు. (ఉత్తమ అసాధారణ పరిస్థితి భద్రతా స్థాయి.)
  2. బలమైన అసాధారణ పరిస్థితి భద్రత లేదా మార్పు ఉండదని హమీ అని కూడా పిలిచే కమిట్ లేదా రోల్‌బ్యాక్ సెమాంటిక్స్ : కార్యాచరణలు విఫలం కావచ్చు, కాని విఫలమైన కార్యాచరణలు ఎటువంటి ప్రతికూల ప్రభావాలను చూపవని హామీ ఉంటుంది, దీని వలన మొత్తం డేటా యదార్ధ విలువలను కలిగి ఉంటుంది.[2]
  3. ప్రాథమిక అసాధారణ పరిస్థితి భద్రత : విఫలమైన కార్యాచరణల పాక్షిక అమలు ప్రతికూల ప్రభావాలను కలిగి ఉండవచ్చు, కాని ఆ దశలోని స్థిరరాశులు మారవు. అసాధారణ పరిస్థితి తర్వాత ముందు విలువలను కాకుండా వేరే విలువలను కలిగి ఉన్నప్పటికీ, ఏదైనా నిల్వ చేయబడిన డేటా చెల్లుబాటు అయ్యే విలువలను కలిగి ఉంటుంది.
  4. ఎటువంటి నష్టం ఉండదని హామీ అని కూడా పిలిచే కనిష్ట అసాధారణ పరిస్థితి భద్రత : విఫలమైన కార్యాచరణల పాక్షిక అమలు కారణంగా చెల్లని డేటా నిల్వ కావచ్చు, కాని క్రాష్ కాదు మరియు ఎటువంటి వనరులను నష్టపోదు.
  5. అసాధారణ పరిస్థితి భద్రత లేదు : ఎటువంటి హామీలు ఉండవు. (పేలవమైన అసాధారణ పరిస్థితి భద్రతా స్థాయి)

ఉదాహరణకు, C++లోని std::vector లేదా జావాలోని ArrayList వంటి ఒక స్మార్ట్ వెక్టర్ రకాన్ని ఎంచుకోండి. ఒక వెక్టర్ v కి ఒక అంశం x ను జోడించినప్పుడు, వెక్టర్ x ను నిజానికి అంశాల అంతర్గత జాబితాకు జోడిస్తుంది మరియు v లోని ఎన్ని అంశాలు ఉన్నాయో సూచించే ఒక గణన క్షేత్రాన్ని కూడా నవీకరిస్తుంది. ఇప్పటికే ఉన్న సామర్థ్యం సరిపోనట్లయితే ఇది నూతన మెమరీని కేటాయించాల్సిన అవసరం కూడా ఉంది. ఈ మెమరీ కేటాయింపు విఫలం కావచ్చు మరియు ఒక అసాధారణ పరిస్థితిని ఏర్పర్చవచ్చు. దీని వలన, వైఫల్య పారదర్శకతను అందించే ఒక వెక్టర్‌ను రాయడం చాలా కష్టంగా లేదా అసాధ్యంగా మారుతుంది. అయితే, వెక్టర్ సులభంగా బలమైన అసాధారణ పరిస్థితి నిర్వహణ హామీని అందించగలదు; ఈ సందర్భంలో, v లోకి x విజయవంతంగా జోడించబడవచ్చు లేదా v మారదు. వెక్టర్ ప్రాథమిక అసాధారణ పరిస్థితి భద్రతా హామీని మాత్రమే అందిస్తే, జోడించడం విఫలమైతే, v x ను కలిగి ఉండవచ్చు లేదా లేకపోవచ్చు, కాని ఇది ఒక స్థిరమైన స్థితిలో ఉంటుంది. అయితే, వెక్టర్ కనిష్ట హామీని మాత్రమే కలిగి ఉంటే, వెక్టర్ చెల్లని అంశంగా మారే అవకాశం ఉంది. ఉదాహరణకు, v యొక్క పరిమాణ క్షేత్రం పెరిగినప్పటికీ, x నిజానికి జోడించబడక, పరిస్థితిని అస్థిరంగా మారుస్తుంది. ఎటువంటి హామీ లేకుండా, ప్రోగ్రామ్ నాశనం కావచ్చు; ఎందుకంటే వెక్టర్ విస్తరించబడాలి కాని మెమరీని కేటాయింలు జరగలేదు మరియు కేటాయింపు విజయవంతమైనట్లు ముందుకు కొనసాగుతుంది, మెమరీ చెల్లని చిరునామాను కలిగి ఉంటుంది.

సాధారణంగా కనీసం ప్రాథమిక అసాధారణ పరిస్థితి భద్రత అవసరమవుతుంది. వైఫల్య పారదర్శకతను అమలు చేయడం చాలా కష్టంగా చెప్పవచ్చు మరియు ఇది సాధారణంగా అనువర్తనం యొక్క సంపూర్ణ విజ్ఞానం అందుబాటులో లేని లైబ్రరీల్లో సాధ్యం కాదు.

అసాధారణ పరిస్థితి నిర్వహణ ధ్రువీకరణ[మార్చు]

అసాధారణ పరిస్థితి నిర్వహణ రొటీన్‌ల ఉద్దేశ్యం ఆ కోడ్ ప్రతికూల పరిస్థితులను నిర్వహించగలదని నిర్ధారించడంగా చెప్పవచ్చు. అసాధారణ పరిస్థితి నిర్వహణ రొటీన్‌లను ఖరాఖండిగా ఏర్పాటు చేయడానికి, కోడ్‌ను విస్తృత స్థాయిలో చెల్లని లేదా ఊహించని ఇన్‌పుట్‌లతో అందించాల్సిన అవసరం ఉంది, ఇటువంటి వాటిని సాఫ్ట్‌వేర్ దోషాలను జోడించడం మరియు ఉత్పరివర్తన పరీక్ష (దీనిని కొన్నిసార్లు అస్పష్టమైన పరీక్ష వలె కూడా సూచిస్తారు) ద్వారా రూపొందించబడతాయి. అసాధారణ పరిస్థితి నిర్వహణ రొటీన్‌లను రాయడం చాలా క్లిష్టమైన సాఫ్ట్‌వేర్ రకాల్లో ఒకటి ప్రోటోకాల్ సాఫ్ట్‌వేర్, ఒక ఖరాఖండి ప్రోటోకాల్ అమలులో సంబంధిత వివరణలతో సంబంధం లేని ఇన్‌పుట్‌ను అందుకోవడానికి సిద్ధంగా ఉండాలి.

ఒక సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ లైఫ్‌సైకిల్ విధానంలో ఒక అర్థవంతమైన తిరోగమన విశ్లేషణ నిర్వహించబడిందని నిర్ధారించడానికి, ఏదైనా అసాధారణ పరిస్థితి నిర్వహణ ధ్రువీకరణ ఎక్కువగా స్వయంచాలకంగా ఉండాలి మరియు టెస్ట్ కేస్‌లను ఒక శాస్త్రీయ, పునరావృత పద్ధతిలో ఉత్పత్తి చేయాలి. వాణిజ్యపరంగా అందుబాటులో ఉన్న పలు వ్యవస్థలు ఇటువంటి పరీక్షను నిర్వహిస్తున్నాయి.

ప్రోగ్రామింగ్ లాంగ్వేజ్‌ల్లో అసాధారణ పరిస్థితి మద్దతు[మార్చు]

యాక్షన్‌స్క్రిప్ట్, అడా, బిల్జ్‌మ్యాక్స్, C++, D, ECMAScript, ఈఫిల్, జావా, ML, ఆబ్జెక్ట్ పాస్కల్ (ఉదా. డెల్ఫీ, ఫ్రీ పాస్కెల్, మరియు అటువంటివి), ఆబ్జెక్టివ్-C, ఓసామ్ల్, PHP (వెర్షన్ 5 వంటి), PL/1, ప్రోలాగ్, పైథాన్, REALbasic, రూబీ, విజువల్ ప్రోలాగ్ మరియు అధిక .NET లాంగ్వేజ్‌లు అసాధారణ పరిస్థితులకు మరియు అసాధారణ పరిస్థితి నిర్వహణకు మద్దతును కలిగి ఉన్నాయి. ఈ లాంగ్వేజ్‌ల్లో, ఒక అసాధారణ పరిస్థితిలో (స్పష్టంగా, లాంగ్వేజ్‌చే నిర్వహించబడుతున్న ఒక అసాధారణ పరిస్థితి) ఒక అసాధారణ పరిస్థితి నిర్వాహకుడి కనిపించే వరకు ఫంక్షన్ స్టాక్‌ను నిశితంగా శోధిస్తాయి, కొన్ని లాంగ్వేజ్‌ల్లో శోధన జరుగుతున్న సమయంలో స్టాక్‌ను వేరు చేసేందుకు ప్రయత్నిస్తాయి. దీని అర్థం, అసాధారణ పరిస్థితి E కోసం ఒక H నిర్వాహకుడిని కలిగి ఉన్న f ఫంక్షన్ g ఫంక్షన్‌ను అభ్యర్థిస్తుంది, అది మళ్లీ h ఫంక్షన్‌ను అభ్యర్థిస్తుంది మరియు h లో అసాధారణ పరిస్థితి E సంభవిస్తుంది, అప్పుడు h మరియు g ఫంక్షన్‌లు ముగించబడతాయి మరియు f లోని H E ని నిర్వహిస్తుంది. ఇది సాధ్యంకాని అసాధారణ పరిస్థితి నిర్వహణ లాంగ్వేజ్‌గా కామన్ లిస్ప్‌ను చెప్పవచ్చు, ఇది దాని నియత వ్యవస్థతో పనిచేస్తుంది. కామన్ లిస్ప్ అసాధారణ పరిస్థితి నిర్వాహకుడిని అభ్యర్థిస్తుంది మరియు స్టాక్‌ను వేరు చేయదు. ఇది లోపం ఏర్పడిన ఖచ్చితమైన స్థానంలోనే గణనను కొనసాగించడానికి అనుమతిస్తుంది ( ఉదాహరణకు ఒక మునుపటిలో లభ్యతలో లేని ఫైల్ ఇప్పుడు అందుబాటులో ఉంటుంది). మైథ్రైల్ యొక్క స్టాక్‌రహిత అమలు స్టాక్‌ను వేరుచేయకుండా స్థిరమైన-సమయ అమలు నిర్వహణకు మద్దతు ఇస్తుంది.

స్వల్ప వాక్యనిర్మాణ వ్యత్యాసాలు మినహా, కొన్ని అసాధారణ పరిస్థితి నిర్వహణ శైలులు మాత్రమే అందుబాటులో ఉన్నాయి. ప్రముఖ శైలిలో, ఒక అసాధారణ పరిస్థితి అనేది ఒక అసాధారణ అంశంతో ప్రత్యేక వాక్యంచే (throw లేదా raise) లేదా ఒక ప్రత్యేక విస్తారిత మార్పు రకం (ఉదా. అడాతో) యొక్క ఒక విలువచే సంభవిస్తుంది. అసాధారణ పరిస్థితి నిర్వాహకుల పరిధి ఒక మార్కెర్ క్లాజ్‌తో (try, లేదా begin వంటి లాంగ్వేజ్ యొక్క బ్లాక్ ప్రారంభం) ప్రారంభమవుతుంది మరియు మొదటి నిర్వాహకుని క్లాజ్ (catch, except, rescue) ప్రారంభంలో ముగుస్తుంది. తర్వాత పలు నిర్వాహక క్లాజ్‌లను రాయవచ్చు మరియు ప్రతిఒక్కటి అతని నిర్వహించే అసాధారణ పరిస్థితి రకాలను మరియు అసాధారణ అంశానికి అవి ఉపయోగించే పేర్లను పేర్కొనవచ్చు. కొన్ని లాంగ్వేజ్‌లు ఎటువంటి అసాధారణ పరిస్థితి సంభవించనట్లయితే నిర్వాహక వ్యవస్థ ముగియడానికి ముందు ఒక క్లాజ్ (else)ను కూడా అనుమతిస్తాయి. సర్వసాధారణ అంశం ఏమిటంటే ఒక సంబంధిత క్లాజ్ (finally లేదా ensure), ఇది ఒక అసాధారణ పరిస్థితి ఏర్పడిన, లేకున్నా అమలు అవుతుంది, సాధారణంగా ఇది అసాధారణ పరిస్థితి నిర్వహణ బ్లాక్‌లో నిర్బంధించబడిన వనరులను విడుదల చేయడానికి ఉపయోగపడుతుంది. ముఖ్యంగా, C++లో ఈ నిర్మాణం అవసరం లేదు మరియు మద్దతు ఇవ్వదు మరియు బదులుగా వనరులను విడుదల చేయడానికి రిసోర్స్-అక్యూజేషన్-ఈజ్-ఇన్సిలైజేషన్ సాంకేతికతను ఉపయోగించాలి[3]. ఈ మొత్తంలో, అసాధారణ పరిస్థితి నిర్వహణ కోడ్ క్రింది ఈ విధంగా ఉండవచ్చు (జావా వంటి సూడోకోడ్‌లో; EmptyLineException అని పిలిచే ఒక అసాధారణ పరిస్థితి రకాన్ని డిక్లేర్ చేయాలని గుర్తించుకోండి): ఒక స్వల్ప మార్పువలె, కొన్ని లాంగ్వేజ్‌లు ఏకైక నిర్వాహక క్లాజ్‌ను ఉపయోగిస్తాయి, ఇది అంతర్గతంగా అసాధారణ పరిస్థితి తరగతిని నిర్వహిస్తుంది.

C పలు దోష తనిఖీలకు మద్దతు ఇస్తుంది, కాని సాధారణంగా ఇది "అసాధారణ పరిస్థితి నిర్వహణ"కు మద్దతుగా పరిగణించరు. పెర్ల్ నిర్మాణ అసాధారణ పరిస్థితి నిర్వహణకు మద్దతును అందిస్తుంది.

C++ ఉత్పన్నం ఎంబెడెడ్ C++ అసాధారణ పరిస్థితి నిర్వహణకు మద్దతును కలిగి ఉండదు ఎందుకంటే ఈ విధంగా చేయడం వలన ఆబ్జెక్ట్ కోడ్ పరిమాణం పెరిగిపోతుంది.

దీనికి విరుద్ధంగా అసాధారణ పరిస్థితి నిర్వహణకు పైథాన్ యొక్క మద్దతు సర్వ వ్యాప్తం మరియు స్థిరంగా ఉంటుంది. try: నిర్దిష్ట చర్యలకు మద్దతు లేకుండా మరియు పలు except: గుర్తించకుండా ఒక ఖచ్చితమైన పైథాన్ ప్రోగ్రామ్‌ను రాయడం చాలా క్లిష్టంగా చెప్పవచ్చు.

అసాధారణ పరిస్థితి నిర్వహణ అమలు[మార్చు]

అసాధారణ పరిస్థితి నిర్వహణ అమలులో సాధారణంగా ఒక కంపైలర్‌తో పాటు కోడ్ జనరేటర్ మరియు రన్‌టైమ్ సిస్టమ్ నుండి తగిన శాతంలో మద్దతు లభిస్తుంది. (ఇది యదార్థ C++ కంపైలర్ Cfront యొక్క వినియోగ జీవితకాలం ముగించిన C++కు అసాధారణ నిర్వహణకు జోడింపుగా చెప్పవచ్చు. [citation needed]) రెండు పద్ధతులు సర్వసాధారణం. మొదటిది, డైనమిక్ రిజిస్ట్రేషన్ అనేది అసాధారణ పరిస్థితి నిర్వహణ ప్రకారం ప్రోగ్రామ్ స్థితి ఆధారంగా నిరంతరం నిర్మాణాలను నవీకరించే కోడ్‌ను ఉత్పత్తి చేస్తుంది.[4] సాధారణంగా, ఇది స్టాక్ ఫ్రేమ్ నమూనాకు ఒక నూతన కారకాన్ని జోడిస్తుంది, ఇది ఆ ఫ్రేమ్‌తో అనుబంధించబడిన ఫంక్షన్ లేదా మెథడ్‌కు లభ్యతలో ఉన్న నిర్వాహకులను గుర్తిస్తుంది; ఒక అసాధారణ పరిస్థితి ఎదురైనప్పుడు, నమూనాలోని ఒక పాయింటర్ రన్‌టైమ్‌ను సరైన నిర్వాహక కోడ్‌కు తీసుకుని వెళుతుంది. ఈ విధానం ఖాళీ స్థలం ప్రకారం చాలా తక్కువ స్థలం ఆక్రమిస్తుంది కాని ఫ్రేమ్ ప్రవేశం మరియు నిష్క్రమణలో అధిక అమలు ఒత్తిడికి కారణమవుతుంది. దీనిని సాధారణంగా పలు అడా అమలుల్లో ఉపయోగిస్తారు, ఉదాహరణకు, పలు ఇతర లాంగ్వేజ్ లక్షణాలకు ఇప్పటికే క్లిష్టమైన జనరేషన్ మరియు రన్‌టైమ్ మద్దతు అవసరమవుతుంది. పేర్కొనడానికి చాలా సులభంగా ఉండే డైనమిక్ రిజిస్ట్రేషన్ అనేది ఖచ్చితత్వానికి నిర్ధారణకు అనుకూలమైనది.[5]

రెండవ పద్ధతి మరియు పలు ప్రొడక్షన్-నాణ్యత C++ కంపైలర్‌ల్లో అమలు చేసే ఒకటి ఒక పట్టిక-ఆధారిత విధానంగా చెప్పవచ్చు. ఇది కంపైల్ మరియు లింక్ సమయంలో స్థిరమైన పట్టికలను రూపొందిస్తుంది, ఇవి అసాధారణ పరిస్థితి నిర్వహణకు అనుగుణంగా ప్రోగ్రామ్ స్థితికి ప్రోగ్రామ్ కౌంటర్ పరిధులను అనుసంధానిస్తుంది.[6] తర్వాత, ఒక అసాధారణ పరిస్థితి ఏర్పడినట్లయితే, రన్‌టైమ్ సిస్టమ్ పట్టికల్లో ప్రస్తుత సూచన స్థానాన్ని శోధిస్తుంది మరియు అమలులో ఉన్న నిర్వాహక వ్యవస్థలను మరియు ఏమి చేయాలో నిర్ణయిస్తుంది. ఈ విధానం ఒక అసాధారణ పరిస్థితి సంభవించని సందర్భంలో అమలు భారాన్ని తగ్గిస్తుంది, కాని కొంత ఖాళీ స్థలంలోనే, అయితే కావల్సిన ఖాళీ స్థలం రీడ్-ఓన్లీలో మాత్రమే కేటాయించబడుతుంది, ఒక అసాధారణ పరిస్థితి ఏర్పడే వరకు ప్రత్యేక-అవసర డేటా విభాగాలు లోడ్ కావు.[7] ఈ రెండవ విధానం థ్రెడ్ భద్రతను పొందడంలో కూడా ఉత్తమమైనదిగా చెప్పవచ్చు.

ఇతర వివరణాత్మక మరియు అమలు చేయగల పద్ధతులు కూడా ప్రతిపాదించబడ్డాయి.[8] మెటాప్రోగ్రామింగ్‌కు మద్దతు ఇచ్చే లాంగ్వేజ్‌ల కోసం, ఎటువంటి ఒత్తిడి లేని విధానాలు అభివృద్ధి చేయబడ్డాయి.[9]

కాంట్రాక్ట్ ద్వారా రూపకల్పన ఆధారంగా అసాధారణ పరిస్థితి నిర్వహణ[మార్చు]

వేరొక రకం అసాధారణ పరిస్థితులు డిజైన్ బై కాంట్రాక్ట్ యొక్క సూత్రాల ఆధారంగా నిర్వచించబడతాయి మరియు ఇది ప్రత్యేకంగా ఈఫిల్ లాంగ్వేజ్‌లో మద్దతు ఉంటుంది. దీని ఉద్దేశ్యం ఏమిటంటే "సాధారణ" మరియు "అసాధారణ" పరిస్థితులను పేర్కొనడం ద్వారా అసాధారణ పరిస్థితి నిర్వహణకు మరింత ఖచ్ఛితమైన పద్ధతిని అందించడాన్ని చెప్పవచ్చు. ప్రత్యేకంగా, ఈ విధానం రెండు అంశాలపై ఆధారపడి ఉంటుంది:

  • వైఫల్యం : ఒక కార్యచరణ దాని ఒప్పందాన్ని నెరవేర్చలేని అసమర్థత. ఉదాహరణకు, ఒక సంకలనం ఒక అంకగణిత లోపాలను ఉత్పత్తి చేయవచ్చు (ఇది గణితశాస్త్ర మొత్తానికి ఒక మంచి అంచనాను లెక్కించే ఒప్పందాన్ని పూర్తి చేయలేకపోయింది); లేదా ఒక రొటీన్ దాని తదుపరి పరిస్థితులను చేరుకోవడంలో విఫలంకావచ్చు.
  • అసాధారణ పరిస్థితి : ఒక రొటీన్ దాని అమలులో సంభవించే ఒక అసాధారణ పరిస్థితి (ఆ రొటీన్ అసాధారణ పరిస్థితికి "గ్రహీత "గా చెప్పవచ్చు). ఒక కార్యాచరణ యొక్క వైఫల్యం ఫలితంగా సంభవించిన ఇటువంటి అసాధారణ అంశం రొటీన్‌చే అభ్యర్థించబడుతుంది.

ఆబ్జెక్ట్-ఓరియెంటెడ్ సాఫ్ట్‌వేర్ కన్‌స్ట్రక్షన్‌లో బెర్ట్రాండ్ మేయర్‌చే ప్రవేశపెట్టబడిన "సురక్షితమైన అసాధారణ పరిస్థితి నిర్వహణ సూత్రం" ప్రకారం ఒక అసాధారణ పరిస్థితి ఏర్పడినప్పుడు, ఒక రొటీన్ రెండు అర్థవంతమైన విధానాల్లో మాత్రమే ప్రతిస్పందిస్తుంది:

  • వైఫల్యం లేదా "వ్యవస్థీకృత భయం": రొటీన్ విఫలమవడం ద్వారా, దాని కాలర్‌లో ఒక అసాధారణ పరిస్థితిని ఏర్పరుస్తుంది (దీని వలన అసాధారణ సందర్భం విస్మరించబడదు

!), తర్వాత స్థిరత్వాన్ని మళ్లీ వ్యవస్థాపించడం ద్వారా ఆబ్జెక్ట్ స్థితిని స్థిరీకరిస్తుంది ("వ్యవస్థీకృత" విభాగం).

  • పునఃప్రయత్నం: మళ్లీ ఆల్గారిథమ్‌ను ప్రయత్నిస్తుంది, సాధారణంగా కొన్ని విలువ మారిన తర్వాత ఈ విధంగా జరుగుతుంది, దీని వలన తదుపరి ప్రయత్నం విజయవంతమయ్యే అవకాశాలు ఎక్కువగా ఉంటాయి.

ఈఫిల్ సింటాక్స్‌లో ఒక ఉదాహరణ క్రింది ఇవ్వబడింది. దీనిలో ఒక రొటీన్ send_fast అనేది సాధారణంగా ఒక సందేశాన్ని పంపడానికి ఉత్తమమైన విధానం, కాని ఇది విఫలమై, ఒక అసాధారణ పరిస్థితిని ఏర్పర్చవచ్చు; ఇలా జరిగితే, ఆల్గారిథమ్ తర్వాతసారి చాలా అరుదుగా విఫలమై send_slow ను ఉపయోగిస్తుంది. send_slow కూడా విఫలమైనట్లయితే, రొటీన్ పంపడంలో పూర్తిగా విఫలమవుతుంది, దీని వలన కాలర్ ఒక అసాధారణ పరిస్థితిని ఎదుర్కొంటుంది.

send (m: MESSAGE) is

-- Send m through fast link if possible, otherwise through slow link.

local

tried_fast, tried_slow: BOOLEAN

do

if tried_fast then
tried_slow := True
send_slow (m)
else
tried_fast := True
send_fast (m)
end

rescue

if not tried_slow then
retry
end

end </source> బూలియన్ స్థానిక చరరాశులు ప్రారంభంలో తప్పుగా సెట్ చేయబడతాయి. send_fast విఫలమైనట్లయితే, ప్రధాన భాగం (do క్లాజ్) మళ్లీ అమలు అవుతుంది, send_slow ను అమలు చేస్తుంది. send_slow అమలు కూడా విఫలమైనట్లయితే, పునఃప్రయత్నం లేకుండా ముగించడానికి రిస్క్ క్లాజ్ అమలు అవుతుంది (ఆఖరి if లో else క్లాజ్ ఉండదు), దీని వలన మొత్తం రొటీన్ విఫలమవుతుంది.


ఈ విధానం ఒక "సాధారణ" మరియు "అసాధారణ" సందర్భాల్లో ఏమి జరుగుతుందో స్పష్టంగా పేర్కొనే ఘనతను కలిగి ఉంది: ఒక అసాధారణ పరిస్థితిని ఏర్పరిచే ఒక అసాధారణ సందర్భంలో రొటీన్ తన ఒప్పందాన్ని పూర్తి చేయలేకపోతుంది.

ఇది ఒక స్పష్టమైన పాత్రలను పేర్కొంటుంది: do క్లాజ్ (ప్రధాన భాగం) అనేది రొటీన్ యొక్క ఒప్పందాన్ని సాధించడం లేదా సాధించడానికి ప్రయత్నించే ఒక పర్యవేక్షకుడిగా చెప్పవచ్చు; రిస్క్ క్లాజ్ అనేది ఇది విజయం సాధించే అవకాశం ఉన్నట్లయితే, సందర్భాన్ని పునఃస్థాపించడానికి మరియు విధానాన్ని పునఃప్రారంభించడానికి పర్యవేక్షకుడిగా చెప్పవచ్చు, కాని ఇది ఏ విధమైన గణనను నిర్వహించదు.

తనిఖీ చేయబడిన అసాధారణ పరిస్థితులు[మార్చు]

జావా ఆధారిత[10][11] తనిఖీ చేసిన అసాధారణ పరిస్థితుల రూపకర్తలు[12], ఇవి ఒక ప్రత్యేక అసాధారణ పరిస్థితుల సమూహంగా చెప్పవచ్చు. ఒక మెథడ్ కారణంగా సంభవించే తనిఖీ చేయబడిన అసాధారణ పరిస్థితులు మెథడ్ యొక్క సంతకంలో భాగంగా చెప్పవచ్చు. ఉదాహరణకు, ఒక మెథడ్ ఒక IOExceptionను ఏర్పర్చినప్పుడు, ఇది దాని మెథడ్ సంతకంలో ప్రత్యేకంగా ఈ వాస్తవాన్ని నిర్ధారించాలి. ఈ విధంగా సంభవించిన వైఫల్యం ఒక కంపైల్-సమయంలో లోపానికి కారణమవుతుంది.

ఇది OCaml కోసం లభించే అసాధారణ పరిస్థితి తనిఖీలకు సంబంధించినది[13]. OCaml కోసం ఒక బాహ్య సాధనం అనేది పారదర్శకం (అంటే, దీనికి ఎటువంటి సింటాక్స్ వ్యాఖ్యలు అవసరంలేదు) మరియు ఐచ్ఛికం (అంటే, అసాధారణ పరిస్థితులను తనిఖీ చేయకుండా ఒక ప్రోగ్రామ్‌ను కంపైల్ చేసి అమలు చేయడం సాధ్యమవుతుంది, అయితే దీనిని ప్రొడక్షన్ కోడ్‌కు అనుమతించబడదు).

CLU ప్రోగ్రామింగ్ లాంగ్వేజ్‌లో తర్వాత కాలంలో జావా పరిచయం చేసిన దానికి సమానమైన ఒక లక్షణం ఉంది. ఒక ఫంక్షన్ దాని రకాల్లో జాబితా చేయబడిన అసాధారణ పరిస్థితులకు మాత్రమే కారణమవుతుంది, కాని అభ్యర్థిస్తున్న ఫంక్షన్‌ల నుండి ఏదైనా జాబితాలో లేని అసాధారణ పరిస్థితి కంపైల్-సమయంలో లోపం వలె సూచించకుండా స్వయంచాలకంగా ఏకైక రన్‌టైమ్ అసాధారణ పరిస్థితి వైఫల్యంగా మారవచ్చు. తర్వాత, మాడులా-3 ఇలాంటి లక్షణాన్నే కలిగి ఉంది.[14] ఈ లక్షణాలు తనిఖీ చేయబడిన అసాధారణ పరిస్థితుల్లో ముఖ్యాంశమైన కంపైల్ సమయంలో తనిఖీని నిర్వహించవు మరియు వీటిని జావాలో మినహా (2006నాటికీ) ఇతర ప్రధాన లాంగ్వేజ్‌ల్లో ఉపయోగించలేదు.[15]

C++ ప్రోగ్రామింగ్ లాంగ్వేజ్ అసాధారణ పరిస్థితి నిర్దేశాలు అని పిలిచే తనిఖీ చేయబడిన అసాధారణ పరిస్థితుల కోసం ఒక వైకల్పిక యాంత్రిక విధానాన్ని పరిచయం చేసింది. స్వయంసిద్ధంగా, ఏదైనా ఫంక్షన్ ఏదైనా అసాధారణ పరిస్థితికి కారణం కావచ్చు, కాని ఇది ఆ ఫంక్షన్‌కు జోడించిన ఒక throw క్లాజ్‌చే పరిమితం చేయవచ్చు, ఇది ఆ ఫంక్షన్ కారణమయ్యే అసాధారణ పరిస్థితులను పేర్కొంటుంది. అసాధారణ పరిస్థితి నిర్దేశాలు కంపైల్-సమయంలో అమలు చేయబడవు. గ్లోబల్ ఫంక్షన్ std::unexpectedలో ఏర్పడిన అతిక్రమణలు అభ్యర్థించబడతాయి.[16] ఒక ఖాళీ అసాధారణ పరిస్థితి నిర్దేశాన్ని పేర్కొనవచ్చు, ఇది ఆ ఫంక్షన్ ఎటువంటి అసాధారణ పరిస్థితికి కారణంకాదని సూచిస్తుంది. లాంగ్వేజ్‌కు అసాధారణ పరిస్థితి నిర్వహణను జోడించినప్పుడు, దీనిని స్వయంసిద్ధంగా చేయరు, ఎందుకంటే ఈ విధంగా చేయడానికి ప్రస్తుతం ఉన్న కోడ్‌లో అత్యధిక మార్పులు అవసరమవుతాయి, ఇది మరొక లాంగ్వేజ్‌లో రాసిన కోడ్‌తో సంబంధాన్ని నిరోధిస్తుంది మరియు స్థానిక స్థాయిలో పలు నిర్వాహక వ్యవస్థలను రాసేందుకు ప్రోగ్రామర్‌లను ప్రోత్సహిస్తుంది.[16] అయితే ఖచ్చితంగా ఖాళీ అసాధారణ పరిస్థితి నిర్దేశాలు వాడకం వలన C++ కంపైలర్‌లు ఒక ఫంక్షన్‌లో అసాధారణ పరిస్థితి నిర్వహక వ్యవస్థ అమలు అవుతున్నప్పుడు సాధారణంగా తొలగిపోవల్సిన ముఖ్యమైన కోడ్ మరియు స్టాక్ నమూనా ఆప్టిమైజేషన్‌లకు అనుమతిస్తుంది.[7] కొంతమంది విశ్లేషకులు C++లో అసాధారణ పరిస్థితి నిర్దేశాల ఖచ్చితమైన ఉపయోగాన్ని సాధించడం చాలా కష్టంగా భావిస్తున్నారు.[17] రాబోయే C++ లాంగ్వేజ్ ప్రమాణంలో (C++0x), ప్రస్తుత ప్రమాణం యొక్క వెర్షన్‌లో (C++03) పేర్కొన్న విధంగా అసాధారణ పరిస్థితి నిర్దేశాల వాడకం నిరాశ కలిగిస్తుంది.

వాడకంపై అభిప్రాయాలు[మార్చు]

కంపైల్ సమయంలో తనిఖీ చేయబడిన అసాధారణ పరిస్థితులు ఒక అనువర్తనంలో రన్‌టైమ్‌లో సంభవించే నిర్వహించని అసాధారణ పరిస్థితుల సంఘటనలను తగ్గిస్తుంది; తనిఖీ చేయబడిన అసాధారణ పరిస్థితులు (RuntimeExceptions మరియు Errors) నిర్వహించబడవు. [citation needed]

అయితే, తనిఖీ చేయబడిన అసాధారణ పరిస్థితులకు విస్తృత throws అవసరమవుతాయి, అమలు అయ్యే వివరాలను బహిర్గతం చేయడం మరియు సంపుటీకరణాన్ని తగ్గిస్తుంది లేదా వారి సంబంధిత నిర్వాహక వ్యవస్థల నుండి నిషిద్దమైన అసాధారణ పరిస్థితులను దాచే పేలవంగా కోడ్ చేసిన try/catch బ్లాక్‌లను ప్రోత్సహిస్తుంది.[citation needed] ఒక సమయంలో అభివృద్ధి చెందుతున్న codebaseను తీసుకోండి. X & Y అసాధారణ పరిస్థితులు కోసం ఒక ఇంటర్‌ఫేస్‌ను రూపొందించవచ్చు. కోడ్ యొక్క తర్వాత వెర్షన్‌లో, Z అసాధారణ పరిస్థితి ఏర్పడేలా చేయాలనుకుంటే, ఇది నూతన కోడ్‌ను మునుపటి ఉపయోగాలకు అననుకూలంగా చేస్తుంది. ఇంకా, అడాప్టర్ నమూనాతో, కోడ్‌లోని ఒక ప్రధాన భాగం కోడ్‌లోని వేరొక ప్రధాన భాగంచే అమలు చేయబడే ఒక ఇంటర్‌ఫేస్‌ను రూపొందించవచ్చు, దీని వలన కోడ్ ముందుగా ప్రారంభమవుతుంది మరియు ముందుగా అభ్యర్థించబడుతుంది, అడాప్టర్ కోడ్ సమస్యలను పేర్కొనడానికి ఉత్తమమైన అసాధారణ పరిస్థితుల సమూహాన్ని కలిగి ఉండవచ్చు, కాని ఇంటర్‌ఫేస్‌లో నిర్ధారించిన అసాధారణ పరిస్థితి రకాలను మాత్రమే ఉపయోగించేలా నిర్బంధిస్తుంది. [by whom?]

అన్ని సంభవించే శక్తివంతమైన అసాధారణ పరిస్థితులకు ఒక ఉపసమితిని నిర్ధారించడం ద్వారా లేదా అభ్యర్థించబడే మెథడ్ యొక్క కృత్రిమ స్థాయికి తగిన అసాధారణ పరిస్థితిని పేర్కొనడం లేదా నిర్దారించడం ద్వారా[18] మరియు ఈ రకాలకు దిగువ స్థాయి అసాధారణ పరిస్థితులను ముఖ్యంగా, ప్రధాన కారణాన్ని నిల్వ చేయడానికి అసాధారణ పరిస్థితి శృంఖలాలను ఉపయోగించి సమూహం చేసిన వాటిని అనుబంధించడం ద్వారా తనిఖీ చేయబడిన అసాధారణ పరిస్థితుల సంఖ్యను తగ్గించడం సాధ్యమవుతుంది. ఇంకా, పైన పేర్కొన్న ఉదాహరణల్లో అభ్యర్థిస్తున్న కోడ్ యొక్క మారే ఇంటర్‌ఫేస్‌ను కూడా సవరించాలి, ఎందుకంటే కొన్ని అసాధారణ పరిస్థితుల్లో ఒక మెథడ్ కారణమయ్యే అంశాలు మెథడ్‌లోని అవ్యక్త ఇంటర్‌ఫేస్‌లో భాగంగా చెప్పవచ్చు.

ఒక కనిష్ట throws Exception నిర్ధారణ లేదా catch (Exception e)ను ఉపయోగించి తనిఖీని సంతృప్తిపర్చడానికి అనుకూలంగా ఉంటుంది. ఇది కొన్ని ఉపయోగాలను కలిగి ఉన్నప్పటికీ, ఇది ప్రాథమికంగా తనిఖీ చేయబడిన అసాధారణ పరిస్థితి యాంత్రిక విధానాన్ని దాటవేస్తుంది. ఇంకా, throws Exception మొత్తం అభ్యర్థన కోడ్ ఈ విధంగా చేసేలా చేస్తుంది. [by whom?]

తనిఖీ చేయబడిన అసాధారణ పరిస్థితి రకాలు పరిధిలో అత్యధిక స్థాయిలో పరిశీలనతో మినహా నిర్వహించబడవు. ఇవి తరచూ పునరుద్ధరణకు అనుమతించని సందర్భాలను సూచిస్తాయి: RuntimeExceptionలు తరచూ ప్రోగ్రామింగ్ దోషాలను ప్రతిబింబిస్తాయి,[19] మరియు Errorలు సాధారణంగా పునరుద్ధరించలేని JVM వైఫల్యాలను సూచిస్తాయి. ఇక్కడ ఉద్దేశ్యం ఏమిటంటే, తనిఖీ చేయబడిన అసాధారణ పరిస్థితులకు మద్దతు ఇచ్చే లాంగ్వేజ్‌లో కూడా, తనిఖీ చేయబడిన అసాధారణ పరిస్థితుల వాడకం అననుకూలమైన సందర్భాలు ఉన్నాయి. [by whom?]

అసాధారణ పరిస్థితి సమకాలీకరణ[మార్చు]

తనిఖీ చేయబడిన అసాధారణ పరిస్థితులతో కొంతవరకు సంబంధం కలిగి ఉన్న అంశంగా అసాధారణ పరిస్థితి సమకాలీకరణ ను చెప్పవచ్చు. సమకాలిక అసాధారణ పరిస్థితులు ఒక నిర్దిష్ట ప్రోగ్రామ్ అంశం వద్ద సంభవిస్తాయి, అయితే అసమకాలిక అసాధారణ పరిస్థితులు ఆచరణీయంగా ఎక్కడైనా సంభవించవచ్చు.[20][21] దీని ప్రకారం అసమకాలిక అసాధారణ పరిస్థితి నిర్వహణను కంపైలర్ నిర్వహించవల్సిన అవసరం లేదని తెలుస్తుంది. వాటితో ప్రోగ్రామ్ రాయడం కూడా క్లిష్టంగా ఉంటుంది. సహజ అసమకాలిక సందర్భాల ఉదాహరణల్లో, ఒక ప్రోగ్రామ్‌కు అంతరాయం కలిగించడానికి Ctrl-C నొక్కడం మరియు మరొక అమలులో ఉన్న థ్రెడ్ నుండి "ఆపివేయి" లేదా "నిలిపివేయి" వంటి సంకేతాన్ని అందుకోవడం వంటివి ఉన్నాయి.

ప్రోగ్రామింగ్ లాంగ్వేజ్‌లు సాధారణంగా ఇటువంటి అంశాలను అసమకాలిక సందర్భాలను పరిమితం చేయడం ద్వారా నిర్వహిస్తుంది, ఉదాహరణకు జావాలో థ్రెడ్ నిలుపుదల మరియు పునఃప్రారంభించడం వంటి అంశాలు లేవు.[22] బదులుగా, ప్రోగ్రామ్‌లోని అనుకూలమైన స్థానాల్లో లేదా సమకాలీకరణలో మాత్రమే సంభవించే పాక్షిక-అసమకాలిక అసాధారణ పరిస్థితులు కూడా ఉన్నాయి.

నియత వ్యవస్థలు[మార్చు]

కామన్ లిస్ప్, డైలాన్ మరియు స్మాల్‌టాక్‌లు ఒక నియత వ్యవస్థను కలిగి ఉన్నాయి [23] ఇది ముందే పేర్కొన్న నిర్వహణ వ్యవస్థలను కలిగి ఉంటుంది. ఇటువంటి లాంగ్వేజ్‌లు లేదా పరిస్థితుల్లో, ఒక షరతు (కెంట్ పిట్మాన్ ప్రకారం, ఒక "ఒక లోపం యొక్క సాధారణీకరణ") అంటే ఒక ఫంక్షన్ కాల్‌గా చెప్పవచ్చు మరియు కాని అసాధారణ పరిస్థితి నిర్వహక వ్యవస్థ స్టాక్‌ను వేరు చేయడానికి నిర్ణయానికి సమయం ఎక్కువ పడుతుందని తెలుస్తుంది.

షరతులు అసాధారణ పరిస్థితుల యొక్క ఒక సాధారణీకరణగా చెప్పవచ్చు. ఒక షరతు సంభవించినట్లయితే, ఆ షరతును నిర్వహించడానికి ఒక తగిన షరతు నిర్వహణ వ్యవస్థ స్టాక్ క్రమంలో శోధించబడుతుంది మరియు ఎంచుకోబడుతుంది. లోపాలను సూచించని షరతులు సురక్షితంగా నిర్వహించబడవు; వీటి యొక్క ప్రధాన ఉపయోగం ఏమిటంటే వినియోగదారుకు సూచనలు లేదా హెచ్చరికలను తెలియజేస్తాయి.[24]

కొనసాగే అసాధారణ పరిస్థితులు[మార్చు]

ఇది అసాధారణ పరిస్థితి నిర్వహణలో పునఃప్రారంభ నమూనా గా పిలిచే దానికి సంబంధించినది, దీనిలో కొన్ని అసాధారణ పరిస్థితులను కొనసాగతాయి అని చెబుతారు: ఇది నిర్వహక వ్యవస్థలో సరైన చర్యను పూర్తి చేసిన తర్వాత, ఒక అసాధారణ పరిస్థితిని సూచించిన వ్యక్తీకరణకు తిరిగి చేరుకోవడానికి అనుమతిస్తుంది. ఈ నియత వ్యవస్థను సాధారణంగా ఇలా చెప్పవచ్చు: సాధారణ పరిస్థితి యొక్క నిర్వహణ వ్యవస్థలో (కొనసాగే అసాధారణ పరిస్థితి అని కూడా పిలుస్తారు), సంకేత అసాధారణ వ్యవస్థ మరియు నియత నిర్వహణ వ్యవస్థ మధ్య ఉన్న ముందే పేర్కొన్న పునఃప్రారంభ స్థానానికి (పునఃప్రారంభాలు అని కూడా పిలుస్తారు) చేరుకునే అవకాశం ఉంది. పునఃప్రారంభాలు అనేవి కొన్ని మాటలకు సంబంధించిన పరిస్థితుల్లో మూసివేయబడే ఫంక్షన్లుగా చెప్పవచ్చు, ఇది నియత నిర్వహణ వ్యవస్థ నుండి పూర్తిగా నిష్క్రమించడానికి లేదా పాక్షికంగా కూడా స్టాక్‌ను వేరు చేయడానికి ముందే ఈ పరిస్థితిని బాగుచేయడానికి ప్రోగ్రామర్‌ను అనుమతిస్తాయి.

విధానానికి విరుద్ధ యాంత్రిక విధానాన్ని పునఃప్రారంభిస్తుంది[మార్చు]

నియత నిర్వహణ వ్యవస్థలు విధానానికి విరుద్ధమైన యాంత్రిక విధానాన్ని అందిస్తాయి. పునఃప్రారంభాలు లోపం నుండి పునరుద్ధరణకు పలు ఆచరణీయ యాంత్రిక విధానాలను అందిస్తాయి, కాని ఒక సందర్భంలో తగిన యాంత్రిక విధానాన్ని ఎంచుకోదు. ఇది నియత నిర్వహణ వ్యవస్థ యొక్క స్థలంగా చెప్పవచ్చు, ఇది (ఎందుకంటే ఇది ఉన్నత-స్థాయి కోడ్‌లో ఉంటుంది) ఒక విస్తృత వీక్షణకు ప్రాప్తిని అందిస్తాయి.

ఉదాహరణకు: ఒక సింగిల్ syslog ఫైల్ నమోదును అన్వయించడానికి ఒక లైబ్రరీ ఫంక్షన్ ఉందనుకుంది. ఆ నమోదు తప్పుగా ఉన్నట్లయితే ఈ పంక్షన్ ఎలా స్పందించాలి? దీనికి సరైన సమాధానం లేదు ఎందుకంటే ప్రోగ్రామ్‌ల్లో ఇదే లైబ్రరీని పలు వేర్వేరు అవసరాలు కోసం ఉపయోగించాలి. ఒక ఇంటరాక్టివ్ లాగ్-ఫైల్ బ్రౌజర్‌లో, చేయవల్సిన పని ఏమిటంటే నమోదును అన్వయించకుండా తిరిగి అందించాలి, దానితో వినియోగదారు గుర్తించగలరు-కాని ఒక స్వయంచాలక లాగ్-సారాంశ ప్రోగ్రామ్‌లో, చదవలేని క్షేత్రాలకు శూన్య విలువలను అందించడం మంచి మార్గంగా చెప్పవచ్చు, కాని అధిక నమోదులు లోపాలు కలిగి ఉన్నట్లయితే చర్యను నిలిపివేయడం మంచిది.

అంటే, ఈ ప్రశ్నకు ప్రోగ్రామ్ యొక్క విస్తృత లక్ష్యాల ఆధారంగా మాత్రమే సమాధానం ఇవ్వవచ్చు, ఇవి సాధారణ అవసరం కోసం రాసిన లైబ్రరీ ఫంక్షన్‌కు తెలియదు. అయితే, ఒక దోష సందేశంతో నిష్క్రమించడం అనేది అరుదైన ఉత్తమ సమాధానంగా చెప్పవచ్చు. ఒక దోషంతో నిష్క్రమించడానికి బదులుగా, ఈ ఫంక్షన్ కొనసాగించడానికి పలు మార్గాలను అందిస్తూ పునఃప్రారంభాలను ఏర్పాటు చేయవచ్చు-ఉదాహరణకు, లాగ్ నమోదును దాటవేయడం, చదవలేని క్షేత్రాలకు స్వయంసిద్ధ లేదా శూన్య విలువలను సరఫరా చేయడం, లేని విలువను వినియోగదారుని అభ్యర్థించడం లేదా స్టాక్‌ను వేరుచేయకుండా ఉండటం చేయవచ్చు మరియు ఒక దోష సందేశంతో ప్రాసెసింగ్‌ను నిలిపివేయవచ్చు. అందించబడే పునఃప్రారంభాలు లోపాల నుండి పునరుద్ధనకు యాంత్రిక విధానాల ను కలిగి ఉంటుంది; నియత నిర్వహణ వ్యవస్థచే పునఃప్రారంభాల ఎంపిక విధానాన్ని సరఫరా చేస్తుంది.

ఇది కూడా చూడండి[మార్చు]

సూచనలు[మార్చు]

  1. అన్ని అసాధారణ పరిస్థితులు నిర్వహించబడతాయిస జిమ్ విల్కోక్స్, http://poliTechnosis.kataire.com/2008/02/all-exceptions-are-handled.html
  2. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1997/N1077.asc
  3. Bjarne Stroustrup's FAQ
  4. D. కామెరూన్, P. ఫాస్ట్, D. లెంకోవ్, M. మెహ్తా, "ఏ పోర్టబుల్ ఇంప్లెమెంటేషన్ ఆఫ్ C++ ఎక్స్‌ప్షెన్ హ్యాండ్లింగ్", ప్రోసీడింగ్స్ ఆఫ్ ది C++ కాన్ఫరెన్స్ (ఆగస్టువ 1992) USENIX.
  5. గ్రాహమ్ హుటన్, జోయెల్ రైట్, "కంపైలింగ్ ఎక్స్‌ప్షెన్స్ కరక్ట్లీ". ప్రోసీడింగ్స్ ఆఫ్ ది 7th ఇంటర్నేషనల్ కాన్ఫరెన్స్ ఆన్ మ్యాథమెటిక్స్ ఆఫ్ ప్రోగ్రామ్ కన్సట్రక్షన్ , 2004.
  6. Lajoie, Josée (March-April 1994). "Exception handling – Supporting the runtime mechanism". C++ Report 6 (3). 
  7. 7.0 7.1 Schilling, Jonathan L. (August 1998). "Optimizing away C++ exception handling". SIGPLAN Notices 33 (8): 40–47. doi:10.1145/286385.286390. 
  8. "హౌ టు ఇంప్లిమెంట్ సాఫ్ట్‌వేర్ ఎక్స్‌ప్షన్ హ్యాండ్లింగ్", ఇంటెల్ కార్పొరేషన్.
  9. M. హోఫ్, H. మోసెబోక్, P. పిర్కెల్బాయెరి, "జీరో-ఒవర్‌హెడ్ ఎక్స్‌ప్షన్ హ్యాండ్లింగ్ యూజింగ్ మెటాప్రోగ్రామింగ్", ప్రోసీడింగ్స్ SOFSEM'97 , నవంబరు 1997, లెక్చర్ నోట్స్ ఇన్ కంప్యూటర్ సైన్స్ 1338 , pp. 423-431.
  10. LISTSERV 15.0 - RMI-USERS ఆర్కైవ్స్
  11. Google ఆన్సర్స్: ది ఆరిజన్ ఆఫ్ చెకెడ్ ఎక్స్‌ప్షన్స్
  12. జావా లాంగ్వేజ్ స్పెసిఫికేషన్, చాప్టర్ 11.2. http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2
  13. OcamlExc -- యాన్ అన్‌కాట్ ఎక్స్‌ప్షన్స్ ఎనలైజేర్ ఫర్ ఆబ్జెక్టివ్ కామ్ల్
  14. Modula-3 - ప్రోసీజర్ టైప్స్
  15. బ్రూస్ ఎకెల్స్ మైండ్‌వ్యూ, ఇంక్: డజ్ జావా నీడ్ చెకెడ్ ఎక్స్‌ప్షన్స్?
  16. 16.0 16.1 బ్జార్నే స్టౌస్ట్రప్, ది C++ ప్రోగ్రామింగ్ లాంగ్వేజ్ థర్డ్ ఎడిషన్, అడిసన్ వెస్లే, 1997. ISBN 0-201-88954-4. pp. 375-380.
  17. Reeves, J.W. (July 1996). "Ten Guidelines for Exception Specifications". C++ Report 8 (7). 
  18. బ్లోచ్ 2001:178 Bloch, Joshua (2001). Effective Java Programming Language Guide. Addison-Wesley Professional. ISBN 0-201-31005-8. 
  19. బ్లోచ్ 2001:172
  20. అసింక్రోనెస్ ఎక్స్‌ప్షెన్స్ ఇన్ హాస్కెల్ - మార్లో, జోన్స్, మోరాన్ (ResearchIndex)
  21. సేఫ్ అసింక్రోనెస్ ఎక్స్‌ప్షన్స్ ఫర్ పైథాన్. http://www.cs.williams.edu/~freund/papers/02-lwl2.ps
  22. జావా థ్రెడ్ ప్రిమిటివ్ డెప్రికేషన్
  23. వాట్ కండిషన్స్ (ఎక్స్‌ప్షన్స్) ఆర్ రియల్లీ ఎబౌట్
  24. కండిషన్ సిస్టమ్ కాన్సప్ట్స్

బాహ్య లింకులు[మార్చు]