www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - comstl exceptions

reply Adi Shavit <adish gentech.co.il> writes:
Hi,

Some more questions about COMSTL:

   1. When and where should/would one use any and all of the COMSTL
      exceptions?
   2. Have you considered having exception throwing versions of COMSTL
      creation (or other) functions?
   3. Related to (2), has anyone got an alternative to using
      if(FAILED(...))? I remember an old column in WDJ that had a MACRO
      based framework for checking return values, but I was wondering if
      anyone has any other approaches.

Thanks,
Adi
Feb 25 2007
next sibling parent reply Adi Shavit <adish gentech.co.il> writes:
The article I was referring to is "Automate Error Checking with 
Debugging Macros" By Larry Leonard <http://tinyurl.com/yvwy7w>.
It can be found here: <http://tinyurl.com/yvwy7w>
Adi

Adi Shavit wrote:

 Hi,

 Some more questions about COMSTL:

    1. When and where should/would one use any and all of the COMSTL
       exceptions?
    2. Have you considered having exception throwing versions of COMSTL
       creation (or other) functions?
    3. Related to (2), has anyone got an alternative to using
       if(FAILED(...))? I remember an old column in WDJ that had a
       MACRO based framework for checking return values, but I was
       wondering if anyone has any other approaches.

 Thanks,
 Adi
Feb 25 2007
parent "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Didn't get to spend a lot of time reading it - although I know I read it =
when published - but this is not what hresult is like.

It's basically used like:


    stlsoft::ref_ptr<IDispatch>  disp;
    comstl::hresult hr =3D =
comstl::co_create_instance("Pantheios.COM.LoggerManager", disp);

If hr is initialised with a failure code - FAILED(hr) - it throws an =
exception.

  "Adi Shavit" <adish gentech.co.il> wrote in message =
news:eru0pn$1ept$1 digitalmars.com...
  The article I was referring to is "Automate Error Checking with =
Debugging Macros" By Larry Leonard.
  It can be found here: <http://tinyurl.com/yvwy7w>
  Adi

  Adi Shavit wrote:=20
    Hi,

    Some more questions about COMSTL:

      1.. When and where should/would one use any and all of the COMSTL =
exceptions?=20
      2.. Have you considered having exception throwing versions of =
COMSTL creation (or other) functions?=20
      3.. Related to (2), has anyone got an alternative to using =
if(FAILED(...))? I remember an old column in WDJ that had a MACRO based =
framework for checking return values, but I was wondering if anyone has =
any other approaches.=20
    Thanks,
    Adi
Feb 26 2007
prev sibling parent reply "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

1. The whole of the STLSoft exception hierarchy is going to have a =
thorough going over with STLSoft 1.10. Whenever that is ...


2. I have. And discounted it. There are two reasons.

In general, it's not a good idea to do this kind of thing unless the =
different function sets have unambiguously different signatures. For =
example:=20

Without exceptions:

    Thing  *thing_ptr;
    int    res =3D create_Thing("my thing", &thing_ptr);

With exceptions:

    Thing    *thing_ptr =3D create_Thing("my thing");

The absence of the second (out) parameter, and absence of an error =
return value, can be used to connote the throwing of exceptions in the =
second case.


At first blush, it seems like we could do the same for the COMSTL =
creation functions: they take an out parameter - a reference (or =
pointer) to the raw/smart pointer to receive the interface pointer.

This case

    stlsoft::ref_ptr<IDispatch>  disp;
    HRESULT hr =3D =
comstl::co_create_instance("Pantheios.COM.LoggerManager", disp);

clearly does not throw an exception.

We might wish to see a with-exceptions case as:

    stlsoft::ref_ptr<IDispatch>  disp =3D =
comstl::co_create_instance("Pantheios.COM.LoggerManager");

The problem is, of course, that this notional overload of =
co_create_instance() does not know the type of the returned smart =
pointer. So, at best, we'd have to have:

    stlsoft::ref_ptr<IDispatch>  disp =3D =
comstl::co_create_instance<IDispatch>("Pantheios.COM.LoggerManager");

This is arguably little better, syntactically, than the explicit case. =
The semantic advantage would be, of course, that it throws an exception =
if the creation fails.


So that's half of one reason. The other half is that the existing =
functions take a third, defaulted, parameter for the creation context. =
Hence the first example shown above is equivalent to:

    stlsoft::ref_ptr<IDispatch>  disp;
    HRESULT hr =3D =
comstl::co_create_instance("Pantheios.COM.LoggerManager", disp, =
CLSCTX_ALL);

The corresponding with-exceptions case would be=20

    stlsoft::ref_ptr<IDispatch>  disp =3D =
comstl::co_create_instance<IDispatch>("Pantheios.COM.LoggerManager", =
CLSCTX_ALL);

Now there are two overloads that have two parameters. And because these =
are all template functions, the compiler is lost. Crash bang wallop to =
that idea.

The theoretical objection is one I've spoken of before: the lowest level =
abstraction should have a single error-handling paradigm, and because =
(i) such low-level features should support exception-free components, =
and (ii) failure to create a COM object is not an exceptional condition, =
I chose to go with HRESULTS at that level.


3. Yes. I've seen many such schemes, and Synesis has had one for =
donkeys' years - called hresult - but it's just never entered the COMSTL =
branch. However, since you appear to want one, I may take a look at it =
again.


More fundamentally, I'm interested in considering whether there're other =
approaches to, say, the co_create_instance() issue.

I just don't have any time to devote to it at this point, though I'm =
willing to chat about ideas. ;-)

  "Adi Shavit" <adish gentech.co.il> wrote in message =
news:ersu3g$2bc8$1 digitalmars.com...
  Hi,

  Some more questions about COMSTL:

    1.. When and where should/would one use any and all of the COMSTL =
exceptions?=20
    2.. Have you considered having exception throwing versions of COMSTL =
creation (or other) functions?=20
    3.. Related to (2), has anyone got an alternative to using =
if(FAILED(...))? I remember an old column in WDJ that had a MACRO based =
framework for checking return values, but I was wondering if anyone has =
any other approaches.=20
  Thanks,
  Adi
Feb 26 2007
parent reply Adi Shavit <adish gentech.co.il> writes:
 1. The whole of the STLSoft exception hierarchy is going to have a 
 thorough going over with STLSoft 1.10. Whenever that is ...


OK.

   
 ...
  
 The theoretical objection is one I've spoken of before: the lowest 
 level abstraction should have a single error-handling paradigm, and 
 because (i) such low-level features should support exception-free 
 components, and (ii) failure to create a COM object is not an 
 exceptional condition, I chose to go with HRESULTS at that level.


OK.

Although I don't do much COM at all, I am not sure (ii) is always true.
If some program assumes the existence/installation of some component 
every time it runs (especially if it installed it itself), then COM is 
conceptually treated just like a statically linked library, i.e. it 
should always be there. The sudden disappearance of the COM object 
should be an exceptional case.


   
 3. Yes. I've seen many such schemes, and Synesis has had one for 
 donkeys' years - called hresult - but it's just never entered the 
 COMSTL branch. However, since you appear to want one, I may take a 
 look at it again.
  
  
 More fundamentally, I'm interested in considering whether there're 
 other approaches to, say, the co_create_instance() issue.


Well, you could always have a different name for the throwing version... 
e.g. co_create_instance_throws().
Feb 26 2007
parent "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
 "Adi Shavit" <adish gentech.co.il> wrote in message


news:eruda9$209k$1 digitalmars.com...

 1. The whole of the STLSoft exception hierarchy is going to have a




thorough going over with STLSoft 1.10. Whenever that is ...

 OK.


 ...

 The theoretical objection is one I've spoken of before: the lowest level




abstraction should have a single error-handling paradigm, and because (i)
such low-level features should support exception-free components, and (ii)
failure to create a COM object is not an exceptional condition, I chose to
go with HRESULTS at that level.

 OK.

 Although I don't do much COM at all, I am not sure (ii) is always true.
 If some program assumes the existence/installation of some component every


time it runs (especially if it installed it itself), then COM is
conceptually treated just like a statically linked library, i.e. it should
always be there. The sudden disappearance of the COM object should be an
exceptional case.


No indeed. It's not a completely black and white thing, which is why I'm
open to working out a way where the exception-throwing stuff can be
incorporated. But it's mostly true, I think, which is why I'm not willing to
trash what we have thus far.

If we can get to a point where we are with the interface casts - where we
have non-throwing and throwing ones that don't interfere (syntactically)
with each other - that'd be great.


 3. Yes. I've seen many such schemes, and Synesis has had one for




donkeys' years - called hresult - but it's just never entered the COMSTL
branch. However, since you appear to want one, I may take a look at it
again.

  > More fundamentally, I'm interested in considering whether there're


other approaches to, say, the co_create_instance() issue.

 Well, you could always have a different name for the throwing version...


e.g. co_create_instance_throws().

He he. But don't you just bristle at the thought of something so pedestrian?
;-)


When I get back to Monolith - next week I hope - I want to use the COM stuff
as the basis for the abstractions chapter. I'm moderately hopeful I can make
something nice of it all. We shall see ... I'll keep you in the picture.



 Feb 26 2007