Exception handling?
in [MFC]
|
Prev: Deriving from a class derived from a CDialog
Next: How to show underlined menu shortcut letters by default for a contextmenu ?
From: RB on 22 Jun 2010 23:29 Actually in summation of all that has transpired on this thread I wanted to clarify my last post. First I realize that if I implement a try then I would also have a catch which I did not show in my previous post. If I needed a try and catch, I feel that you guys have taught me the basics of that. In addition I understand that in many cases one could if circumstances warrant, throw a framework (or other available) exception (or call a function that would throw it ) from a code segment "without" implementing any try and catch. I am still a neophite by any means in this area but this thread has taught me a bunch. And I thank all of you. I am still waiting to get Goran's final input also since the tonights expanded input of this thread in his timezone will catch him asleep.
From: Joseph M. Newcomer on 23 Jun 2010 00:02 Again, the question is performance: if you had to open a file, read data in, and finally invoke the parsing, what percentage of the time is spent handling an exception. An exact number, expressed in some quantity of nanoseconds, microseconds, or milliseconds is essential here. I don't buy "slowness" unless there is a precise quantity specified. And, the absolute number is not relevant either; the number has to be expressed as a percentage of the total processing time required, and once "user time" gets into the mix (a user having to read a MessageBox or something like that) then it becomes a percentage of tens of seconds. I spent 15 years worrying about these issues, and by the end of the work, we measured down to the microsecond (on 1MIPS machines, so we could get resolution down to the single instruction; the architecture, a mainframe, had the equivalent of the x86 RDTSC instruction). One thing I learned, was that anyone who started claiming that "X is a performance problem" was usually basing it on rumor and hearsay; once we instrumented the code, we found performance was often down in single-digit microseconds. And in one case where it was in hundreds of microseconds, the situation was an error that invalidated a complete run of the program, so we'd lost minutes; the extra few hundred microseconds wasn't even worthy of discussion (the time spent formatting the error line to the printer was about an order of magnitude slower than the exception handling, in a language that didn't really have exception handling...just the equivalent of setjmp/longjmp, which he had been told was "slow", as if it mattered). The bottom line: whenever you ask a programmer "Where is the performance bottleneck in your code?", you will get the wrong answer. joe **** On Tue, 22 Jun 2010 19:10:53 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:d0j2261qbnp0hepna91efqiiesg126u0st(a)4ax.com... >> Note that this could be handled as >> >> BOOL TryParse(...args...) >> { >> try >> { >> Parse(...); >> return TRUE; >> } >> catch(..whatever..) >> { >> return FALSE; >> } >> } >> >> It ain't rocket science. And it isn't clear to me how handling the >> exception results in >> "bad code". >> oje >> > >This implementation of TryParse() doesn't solve the problem we were talking >about. The problem is that if an exception is thrown for the common >occurrence of malformed args, the result is it is SLOWNESS! This >implementation would fix this problem: > > BOOL TryParse(...args...) > { > if (!IsValid(args)) > return FALSE; > > Parse(...); // Parse() will not throw because args are valid > return TRUE; > } > > >-- David > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Ching on 23 Jun 2010 00:17 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:181326184ejv0jnpda5olkfjjvu54sadln(a)4ax.com... > An exact number, expressed in some quantity of nanoseconds, microseconds, > or milliseconds > is essential here. I don't buy "slowness" unless there is a precise > quantity specified. > Joe, all I know is the MS architects felt adding TryParse() was necessary in ..NET 2.0 due to the overhead of Parse() throwing exceptions. You can take it up with them. -- David
From: Goran on 23 Jun 2010 02:49 On Jun 22, 5:17 pm, "RB" <NoMail(a)NoSpam> wrote: > Additionally I have this logic going so far. > // in the read loop of MyDoc class serialize > else > { > try > { > ar >> FID_Read;; // DWORD FID_Read; > if (FID_Read != FileID) // const DWORD FileID; > { // FileID mismatch > throw new CWrongFileIDException(); > } > ar >> VerData.Ver >> VerData.CpyRt >> VerData.Corp; > ar.SerializeClass(RUNTIME_CLASS(CMapStringToString)); > ExpMap1.Serialize(ar); > } > catch(CWrongFileIDException* e) > { > // Do whatever I may need here > // so far nothing that I can tell, in fact it seems I could have just > // eliminated my try and catch handlers and just called the > // AfxThrowArchiveException in the if loop above ? > e->Delete( ); > AfxThrowArchiveException(CArchiveException::badIndex, NULL ); //Invalid file format > // The above takes me to the exact same cleanup code that I get when > // I read in a corrupt file (with NO exception code at all ) and mfc handlers it. > // And leaves me with an untitled filename eliminating the change if inadvertant > // save overwrite. > } > } As I said: you are not permitted to write try/catch statements ;-) In this case (wrong "magic" in the file), you have these options (AFAICanSee): 1. use AfxThrowArchiveException with e.g. badIndex (kinda silly name given the associated message, but fair enough). 2. (consequence of the ReportSaveLoadException catch I spoke before) derive your own exception class with whatever info you want, and override ReportSaveLoadException to handle it. You need to override it, because ReportSaveLoadException handles only "archive" and "file" exceptions (doc says it handles "typically a CFileException or CArchiveException", but it in fact handles these in a more precise ways, and for the rest it pops up "generic" message, so you might want to improve on that. But I'd say that 1 is just fine. At any rate, biggest chance of that happening is that somebody is jerking up the file intentionally. Do you want to help these people too much? ;-) Goran.
From: Goran on 23 Jun 2010 02:53
On Jun 22, 7:12 pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote: > >P.S. Don't forget: you are not allowed to write try/catch > >statements ;-). If you do, you have 99% chance that you're doing it > >wrong. Good C++ code of today has RIDICULOUSLY small number of try/ > >catch-es in ti. > > **** > I'm not sure this is a good piece of advice. I use try/catch a lot; it is essentially a > "non-local GOTO", a structured way of aborting execution and returning to a known place, > while still guaranteeing that all intermediate destructors for stack variables are called. Yes, of course. I can't speak for you without looking at the code, but I am using ScopeGuard a lot (it's a heaven sent for exception safety in C++, and no other language in vicinity comes even close). From the viewpoint of ScopeGuard, there should be virtually no try/catch statements in the code, and there should not be catch(...){ whatever(); throw; } either. Goran. |