From: RB on

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
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
"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
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
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.