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

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
>

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:

Without exceptions:

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

With exceptions:

    Thing    *thing_ptr = 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 = 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 = 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 = 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 = comstl::co_create_instance("Pantheios.COM.LoggerManager", disp, CLSCTX_ALL);

The corresponding with-exceptions case would be

    stlsoft::ref_ptr<IDispatch>  disp = 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?
    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

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 = 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:
    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

> 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().

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