Prev: How to embed a word document in CView
Next: _ATL_NO_EXCEPTIONS conflict
From: Doug Harrison [MVP] on 25 Jun 2010 16:15
On Fri, 25 Jun 2010 00:21:13 -0700 (PDT), Goran <goran.pusic(a)gmail.com>
wrote:

>Other people already explained a lot. I'll just add that in context of
>MFC you should always use exception object derived from some MFC
>exception class, you should throw them like so: throw new
>CMyExceptionClass(params), and you should catch them like so:
>catch(CMyException* pe). This is, sadly, different from "standard C++"
>way of doing things. (see my other post).

See also my web page where I explain how to deal with non-MFC exceptions in
MFC programs, which may be unavoidable when you start introducing other
libraries into your program:

How do I safely use _com_error, std::exception, and other non-MFC exception
classes in MFC programs?
http://members.cox.net/doug_web/eh.htm#Q6

--
Doug Harrison
Visual C++ MVP
From: RB on 25 Jun 2010 19:30

Thanks Doug, I saved a copy of your page for study.
From: Goran on 26 Jun 2010 02:16
On Jun 25, 6:23 pm, "RB" <NoMail(a)NoSpam> wrote:
>   Ok, well all of this is enlightening given I did not even know one
> could return the definition of class and have it constructed on the stack..

Ugh. (I see Joe flamed you about that as well, but it's so bad that
it's not enough ;-) )

Definition of a class is this:

class name { members here }

declaration of a variable (class, struct, typedef, primitive type,
whatever) is this (technically, it's also initialization, see below):

type variable_name(ctor params);

Alternatively, declaration is also:

type variable_name;

But for any type without default ctor (e.g. primitive types) this
should almost never be seen in C++ code.

>   So a reference does help (for the reason you gave) even though it may
> be a small copy, that is interesting. But then I shouldn't have equated the
> stack ownership as any ramification since other items are sometimes on
> the stack also. A reference is a reference I guess, no matter where it references.

Since a thrown exception clearly spans several stack frames, which
stack frame it belongs to, would you say? There's no "stack ownership
ramifications" that you see. So a thrown object "belongs" to language
runtime (to code generated by the compiler, if you will). Runtime does
all for you (obviously, AGAIN, MFC exceptions are different, because
they are pointers; hence the need, under MFC design, to call Delete()
when done).

Goran.
From: RB on 26 Jun 2010 10:39
> Goran wrote:
> .........
>..........

Yes, I have gotten into an area that I am still weak on
conceptualizing. I hear what you are saying and it make sense
to me. I just have not gotten it totally ingrained where I can
see it always at any given moment.

> AGAIN, MFC exceptions are different, because they are
> pointers; hence the need, under MFC design, to call Delete()
> when done).

Yes I did understand all of this earlier and that is where I will
end back up later. But for now I am just writing code to step
thru and see what is going on since this whole new facet of all of this
that I stumbled onto is intriguing. Probably have some questions later.
Thanks as always. RB
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: How to embed a word document in CView
Next: _ATL_NO_EXCEPTIONS conflict