Richard ONeil wrote: > Why is this a terrible example? Well, I gave two reasons.
> If you are worried about your other > exceptions, then build routines to handle them and a generic for ones > that you don't know about. That's much easier to do when the special handlers aren't built into the generic one. Your example caught all exceptions and then checked the type. My alternative only caught that single type. There is rarely a need to check an exception's type with the "is" operator since the structure of exception handlers allows you to perform that check implicitly. Furthermore, most exception handlers *shouldn't* catch generic exceptions. You should never catch an exception you don't know about -- how can you possibly expect to recover from it, after all, when you don't know why it was raised? I get nervous when I see an "except" block that catches bare Exception objects (or worse, when it catches all exceptions, even those that descend directly from TObject -- did you know that exceptions needn't descend from SysUtils.Exception?) when there is a more specific type that could be caught instead. > The message that is being raised was just > an example that you can inform your user that something has happened. The user will only be informed when the new exception gets caught. And the user won't be able to do anything about it except complain to the developer, and the information in that exception message don't help the developer at all. The information in the original exception message would be a lot better, and you could have had that without catching the exception at all. > There is nothing to stop you from logging the actual error that > happened. Why would you scare your user to death by showing them the > actual exception? Be gentle with them. There are ways of showing friendlier error messages without completely discarding the meaningful ones. > By creating different handlers for the known types of errors allows > you to tailor the message that is given back, and handle it > gracefully. > > You are correct that the above example would probably be bad by > itself, but from an educational standpoint, I was hoping that it would > be a good starting point. :) I understand that, but the code you showed wasn't really much beyond what Jeff already had. It's as though you only demonstrated valid *syntax*, but didn't demonstrate how to *handle* an exception. In recent months, I've come to believe that if it's worth writing an example for something, then it's worth writing a _good_ example. It's unfortunate that the latter take so much longer to write. Exceptions, especially, are hard to write about because exception handlers can't be generic. A good exception handler has to know something about the context in which it appears, and it's very hard to provide that kind of context in a small example. It's easy in a big example, but the bigger an example is, the harder it is to make generalizations from it and apply them to real-world code. > I've never used JclDebug....you have me curious about it, though. > Where might I find more information about it? http://jcl.sourceforge.net/ Incidentally, Delphi 2005 with update 2 now uses some of the facilities from the JclDebug unit. When an exception occurs in the IDE, you'll get a dialog box telling you the error message, just like you always have, but the dialog can also display the call stack (useful for reporting bugs on QualityCentral or when you're developing an expert or design-time component) and even e-mail the report to Borland. -- 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/
