Vahan Yoghoudjian wrote: > Why not use the keyword else in the except block?
Because it's no different from catching all exceptions. Do not catch an exception if you don't know how to recover from it. These two blocks of code do identical things: try // ... except on E: EConvertError do HandleConvertError(E); on E: EDatabaseError do HandleDatabaseError(E); else HandleEverythingElse; end; try // ... except on E: EConvertError do HandleConvertError(E); on E: EDatabaseError do HandleDatabaseError(E); on E: TObject do HandleEverythingElse(E); end; What could you possibly put in the implementation of HandleEverythingElse to be sure that it does indeed handle *everything* that could have gone wrong the the "try" section? If you don't know what you would do with that TObject, then you shouldn't replace that exception handler with "else," either. > If I'm aware of an > exception and I know how to deal with it I will, Good. But ignore the rest of the exceptions. > as for every other > exception the message will be displayed... But what happens after that? Will your program keep running? Suppose one of the exceptions you handle with an "else" clause happens to be an EAccessViolation. If you get that exception, then you have some variable that doesn't refer to a valid object -- the internals of your program are unstable. EAccessViolation might also occur if you write beyond the end of an array. Would it really be wise to allow the program to continue running when you have no idea what's wrong under the hood? -- Rob ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [EMAIL PROTECTED] Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/delphi-en/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
