VB2008从入门到精通(PDF格式英文版)-第36部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！


　　　　　　　　　　　　　　　For　example；　say　you　wanted　to　parse　a　number。　The　　parsing　routines　tend　to　give　a　　

　　　　　　　　　　result　if　everything　worked　OK；　but　generate　an　exception　if　things　are　not　OK。　There　is　no　　

　　　　　　　　　　return　value；　just　an　exception。　But　when　parsing　a　number；　you　do　know　that　things　could　go　　

　　　　　　　　　　wrong；　so　you　will　need　to　write　an　exception　handler。　Following　is　some　source　code　that　　

　　　　　　　　　　parses　a　number。　



　　　　　　　　　　Function　TestGetValue（ByVal　buffer　As　String）　As　Integer　

　　　　　　　　　　　　　　Dim　retval　As　Integer　=　0　

　　　　　　　　　　　　　　Try　　

　　　　　　　　　　　　　　　　　　retval　=　Integer。Parse（buffer）　

　　　　　　　　　　　　　　Catch　ex　As　FormatException　

　　　　　　　　　　　　　　　　　　Console。WriteLine（〃Exception　（〃　&　ex。Message　&　〃）〃）　

　　　　　　　　　　　　　　End　Try　

　　　　　　　　　　　　　　Return　retval　

　　　　　　　　　　End　Function　



　　　　　　　　　　　　　　　In　the　example；　the　code　realizes　that　if　Parse（）　is　called　and　the　string　cannot　be　converted　　

　　　　　　　　　　into　a　number　due　to　incorrect　letters　or　numbers；　an　exception　will　be　thrown。　The　exception　　

　　　　　　　　　　will　be　caught；　processed　（using　the　exception’s　Message　property　to　obtain　the　problem）；　and　　

　　　　　　　　　　then　the　value　of　retval　will　be　returned　to　the　caller。　But　what　if　an　exception　does　happen？　　

　　　　　　　　　　The　variable　retval　is　initialized　to　a　default　value　of　0；　which　is　a　valid　formatted　number　and　　

　　　　　　　　　　can　be　interpreted　as　the　result　of　a　successful　format　processing。　


…………………………………………………………Page　153……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　CH　AP　T　E　R　　　5　　　■　　　　L　E　AR　N　IN　G　　　AB　O　U　T　　　V　I　SU　A　L　　　B　AS　IC　　　E　X　CE　PT　I　ON　　　HA　N　D　L　IN　G　131　



　　　　　The　problem　in　the　code　is　that　a　developer　is　caught　in　a　bind。　By　capturing　the　exception；　　

the　method　TestGetValue（）　is　saying；　“I　will　always　return　to　the　caller　a　valid　value。”　Yet　there　　

are　instances　when　a　valid　value　is　not　available。　In　the　case　of　parsing　a　number；　an　exception　　

is　thrown。　So　by　capturing　an　exception；　you　are　doing　the　pletely　wrong　thing；　because　　

you　should　be　letting　the　exception　be　caught　by　a　higher…level　caller。　But　things　can　bee　　

sticky　here。　Do　you　really　want　to　inform　the　caller　that　a　parse　cannot　occur？　Perhaps　the　caller　　

is　more　interested　in　whether　a　valid　value　is　returned。　It’s　like　saying　to　the　CEO；　“Oops；　we　　

just　ran　out　of　staples。”　Sure；　staples　might　be　important；　and　maybe　the　pany　will　not　run　　

as　smoothly；　but　do　you　really　want　to　inform　the　CEO　about　every　little　problem？　

　　　　　Microsoft　developers　know　about　this　problem　with　parsing；　and　use　an　approach　that　　

you　can　use　as　well。　As　you　learned　in　Chapter　3；　there　are　two　variations　of　parsing　a　number：　



　　　　　o　　Parse（）　returns　a　valid　number　if　the　buffer　could　be　parsed；　and　an　exception　if　a　　

　　　　　　　　number　could　not　be　parsed。　



　　　　　o　　TryParse（）　returns　a　True　or　　False　value　indicating　the　result　of　the　parse。　　



　　　　　Here’s　how　you　could　rewrite　the　TestGetValue（）　method　to　use　TryParse（）：　



Function　TestGetValue（ByVal　buffer　As　String；　ByRef　val　As　Integer）　As　Boolean　

　　　　Dim　retval　As　Boolean　=　False　

　　　　If　Integer。TryParse（buffer；　val）　Then　

　　　　　　　　retval　=　True　

　　　　End　If　

　　　　Return　retval　

End　Function　



　　　　　In　the　modified　example；　TestGetValue（）　returns　a　True　or　　False　to　indicate　a　success　or　　

failure　when　parsing　a　number。　If　a　True　is　returned；　the　parameter　val　will　hold　a　valid　number；　　

otherwise；　val　should　be　not　be　used。　

　　　　　Some　of　you　might　have　caught　that　my　use　of　Parse（）　and　TryParse（）　is　not　very　creative。　　

The　method　TestGetValue（）　could　have　been　reduced　to　a　single　line：　



Function　TestGetValue（ByVal　buffer　As　String；　ByRef　val　As　Integer）　As　Boolean　

　　　　Return　Integer。TryParse（buffer；　val）　

End　Function　



Using　Default　State　



Default　state　is　a　useful　technique　to　guard　against　exceptions　that　developers　often　ignore。　　

When　developers　are　writing　their　code；　they　will　often　return　Nothing　when　things　don’t　work　　

out。　Using　Nothing　is　not　a　bad　idea；　but　it　adds　unnecessary　baggage。　For　example；　consider　　

the　following　code：　



Class　DefaultStateWrong　　

　　　　Private　Function　Tokenize（ByVal　buffer　As　String）　As　String（）　

　　　　　　　　Return　Nothing　

　　　　End　Function　


…………………………………………………………Page　154……………………………………………………………

132　　　　　　　CH　AP　T　E　R　　　5　　　■　　　　L　E　A　R　N　IN　G　　　AB　OU　T　　　V　I　SU　A　L　　　B　AS　IC　　　E　X　C　E　P　TI　ON　　　H　AN　D　L　IN　G　



　　　　　　　　　　　　　　Public　Sub　IterateBuffers（ByVal　buffer　As　String）　　

　　　　　　　　　　　　　　　　　　Dim　found　As　String（）　=　Tokenize（buffer）　

　　　　　　　　　　　　　　　　　　If　found　IsNot　Nothing　Then　　

　　　　　　　　　　　　　　　　　　　　　　For　c1　As　Integer　=　0　To　found。Length　1　

　　　　　　　　　　　　　　　　　　　　　　　　　　Console。WriteLine（〃Found　（〃　&　found（c1）　&　〃）〃）　

　　　　　　　　　　　　　　　　　　　　　　Next　

　　　　　　　　　　　　　　　　　　End　If　

　　　　　　　　　　　　　　End　Sub　

　　　　　　　　　　　End　Class　



　　　　　　　　　　　　　　　　The　problem　in　this　example　is　Tokenize（）；　which　is　a　method　used　to　convert　the　param

　　　　　　　　　　eter　buffer　into　a　series　of　string　tokens。　Using　safe　exception　coding；　if　the　data　could　not　be　　

　　　　　　　　　　parsed；　you　could　throw　an　exception；　or　you　could　return　a　Nothing　value　indicating　that　the　　

　　　　　　　　　　buffer　could　not　be　parsed。　

　　　　　　　　　　　　　　　　The　caller　code　knows　that　there　is　the　possibility　of　a　Nothing　value　when　calling　Tokenize（）；　　

　　　　　　　　　　and　thus　has　an　If　test　to　check　for　the　Nothing　value。　The　If　test　is　defensive　coding；　but　it　also　　

　　　　　　　　　　adds　plexity　because　you　need　to　verify　for　a　Nothing　value。　

　　　　　　　　　　　　　　　What　if　Tokenize（）　were　a　bit　smarter　and　decided　to　return　an　empty　array　to　indicate　an　　

　　　　　　　　　　empty　result　set？　The　logic　of　this　is　not　incorrect；　because　the　caller　expects　either　a　result　set　　

　　　　　　　　　　with　items　or　a　result　set　with　nothing　in　it。　If　a　dramatically　bad　parsing　error　has　occurred；　the　　

　　　　　　　　　　only　recourse　is　to　throw　an　exception。　Here　is　the　rewritten　code：　



　　　　　　　　　　Class　DefaultStateRight　　

　　　　　　　　　　　　　　Private　Function　Tokenize（ByVal　buffer　As　String）　　As　String（）　

　　　　　　　　　　　　　　　　　　Return　New　String（…1）　｛　｝　

　　　　　　　　　　　　　　End　Function　



　　　　　　　　　　　　　　Public　Sub　IterateBuffers（ByVal　buffer　As　String）　　

　　　　　　　　　　　　　　　　　　Dim　found　As　String（）　=　Tokenize（buffer）　

　　　　　　　　　　　　　　　　　　For　c1　As　Integer　=　0　To　found。Length　1　

　　　　　　　　　　　　　　　　　　　　　　Console。WriteLine（〃Found　（〃　&　found（c1）　&　〃）〃）　

　　　　　　　　　　　　　　　　　　Next　

　　　　　　　　　　　　　　End　Sub　

　　　　　　　　　　　End　Class　



　　　　　　　　　　　　　　　　In　the　rewritten　code；　Tokenize（）　returns　an　empty　array　that；　when　iterated　using　a　For　　

　　　　　　　　　　loop；　will　cause　zero　iterations。　This　is　exception…safe　code　with　improved　readability。　

　　　　　　　　　　　　　　　　But　what　happens　if　Tokenize（）　does　throw　an　exception？　With　Tokenize（）　throwing　an　　

　　　　　　　　　　exception　and　the　lack　of　a　Try/Catch　block　in　IterateBuffers（）；　it　looks　like　IterateBuffers（）　　

　　　　　　　　　　is　written　incorrectly。　However；　IterateBuffers（）　is　not　written　incorrectly；　because　Tokenize（）　　

　　　　　　　　　　will　throw　an　exception　only　if　something　really　problematic　has　occurred。　A　big　problem　is　　

　　　　　　　　　　beyond　the　scope　of　the　IterateBuffers（）　method；　and　thus　needs　to　be　handled　at　a　higher　　

　　　　　　　　　　level。　Think　of　it　as　the　situation　where　you　have　a　criminal　case　and　the　local　municipal　court　　

　　　　　　　　　　automatically　delegates　the　case　to　the　provincial　or　state　level；　because　those　courts　are　equipped　　

　　　　　　　　　　to　deal　with　such　a　case。　


…………………………………………………………Page　155……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　CH　AP　T　E　R　　　5　　　■　　　　L　E　AR　N　IN　G　　　AB　O　U　T　　　V　I　SU　A　L　　　B　AS　IC　　　E　X　CE　PT　I　ON　　　HA　N　D　L　IN　G　133　



Processing　Errors　That　Are　Warnings　



One　of　the　silliest　things　that　programs　do　is　exit　when　they　could　have　continued　working。　It　　

reminds　me　of　when　my　family　lived　on　the　French　Rivera；　where　it　does　not　rain　too　often。　Our　　

two　bulldogs　were　used　to　the　nice　weather；　and　at　the　slightest　hint　of　moisture　in　the　air；　they　　

would　refuse　to　go　outside。　Our　male　dog　Big　Boss　（Man）　would　stand　in　the　doorway；　stick　his　　

nose　out　slightly；　and　take　a　few　deep　breaths。　If　he　sensed　the　slightest　bit　of　moisture；　instantly　　

you　were　dragging　an　80…pound　concrete　block。　

　　　　　The　point　is　that；　like　our　bulldogs；　programs　sometimes　overreact　to　situations。　For　fear　　

of　having　problems　or　not　doing　something　correctly；　they　instantly　shut　down。　

　　　　　Let’s　say　that　you　have　a　program　that　requires　a　configuration　file　to　run。　What　happens　　

when　the　configuration　file　does　not　exist？　One　approach　is　to　panic　and　exit。　The　panic　approach　　

will　work；　but　what　if　multiple　problems　follow　from　the　first　one？　Then　you　are　painstakingly　　

hitting　one　error　after　another。　Another　approach　is　to　use　a　default　action。　In　this　example；　the　　

default　action　could　be　to　display　a　dialog　box　asking　the　user　to　select　a　configuration　file；　or　　

the　program　could　create　a　default　file；　as　in　this　example：　



Try　　

　　　　LoadConfiguration（）　

Catch　ex　As　ConfigurationException　

　　　　　CreateDefaultConfiguration（）　

End　Try　



　　　　　Here；　the　　LoadConfiguration（）　method　is　in　a　Try/Catch　block；　but　the　Catch　block　　

catches　only　ConfigurationException　failures　（a　built…in　Visual　Basic　exception）。　If　there　is　a　　

ConfigurationException　failure；　then　a　default　configuration　is　created。　With　a　default　config

uration；　the　program　can　continue　processing。　Using　the　filtering　capabilities　of　exceptions；　if　　

another　exception　is　thrown　in　　LoadConfiguration（）；　then　some　higher…level　exception　　

handler　will　process　it。　

　　　　　When　processing　an　error　that　is　a　warning；　the　important　steps　are　to　filter　for　the　specific　　

exception　and　implement　an　appropriate　exception　handler　that　has　been　properly　tested。　Don’t　　

try　to　implement　a　fix…all　exception　handler；　because　you　will　never　be　able　to　implement　a　　

proper　handler　and　thus　will　cause　more　problems。　In　the　handler　to　fix　the　problem；　make　　

sure　that　you　don’t　generate　an　exception。　If　you　do；　that　exception　will　be　sent　to　a　higher　　

method　caller。　



The　Important　Stuff　to　Remember　



In　this　chapter；　you　learned　about　errors　and　exceptions。　Here　are　the　key　points　to　keep　in　mind：　



　　　　　o　　Errors　and　exceptions　will　always　occur　in　your　programs。　



　　　　　o　　Your　code　is　split　into　a　tree　very　much　like　a　management　hierarchy。　The　hierarchy　　

　　　　　　　　contains　two　types　of　code：　code　that　organizes　and　code　that　implements。　　



　　　　　o　　Exceptions　are　caught　using　Try/Catch　blocks。　



　　　　　o　　The　Finally　block　is　used　to　execute　code；　regardless　of　whether　an　exception　is　thrown；　　

　　　　　　　　and　to　reset　state。　


…………………………………………………………Page　156……………………………………………………………

134　　　　　　　CH　AP　T　E　R　　　5　　　■　　　　L　E　A　R　N　IN　G　　　AB　OU　T　　　V　I　SU　A　L　　　B　AS　IC　　　E　X　C　E　P　TI　ON　　　H　AN　D　L　IN　G　



　　　　　　　　　　　　　　　o　　Code　that　implements　has　the　responsibility　of　throwing　exceptions。　Code