[aspectc-user] More demonstrations for applications of AspectC++?

[Olaf Spinczyk]

Hi!

You raised a lot of interesting points. Find my comments below ...

On 11/29/2011 01:41 PM, Markus Elfring wrote:
>> pointcut void_function() = "void ...::%(...)";
>> advice execution("% MyClasss::%(...)" && !void_function()) : ...
>>
>> We have used this in an example in which we transformed C-style error 
>> codes
>> into exceptions.
>
> I would be interested in further fine-tuning for such an advice 
> because of the desired completion of error detection and exception 
> handling. But I would like to point out that a few use cases which 
> will also need further considerations.
>
> 1. Functions with an interface style like strcpy() forward an input 
> parameter as their output.
>
> 2. There are a few functions where the meaning of a successful 
> execution depends completely on the passed input parameters.
> Example: DispatchMessage();
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms644934.aspx
>
> 3. An API documentation might be unclear if an error predicate should 
> be checked.
>
> 4. An output parameter should be checked instead of a value from the 
> function return type (because it might be "void").

Well, yes, there are many variants how to signal error conditions in 
C/C++ software. The aspect-oriented approach described in our paper 
works best if a all functions follow the same general policy. In this 
case a programmer can save a lot of time. However, if each function 
follows a different policy, aspects won't help. In practice you will 
find situations that are somewhere in between these two extremes.

What do you think about the following design? ...

For each external library that you use in a project define a namespace, 
e.g. ...

namespace ext_libxml2 {
...
}

Import all functions of the external library that you *need* into the 
namespace with a using declaration. For special functions that don't 
follow a consistent error signaling style, write small inline wrapper 
functions that modify the error signaling scheme, such as this ...

namespace ext_libxml2 {
   // normal case
   using ...;

   // special case: normally in libxml2 all errors are signaled by -1 as 
return code. Here it can be positive.
   int xmlValidateName (const ::xmlChar 
<http://xmlsoft.org/html/libxml-xmlstring.html#xmlChar> *value, int 
space, int &error_code) {
     error_code = ::xmlValidateName(value, space);
     return ((error_code != 0) ? -1 : 0);
   }
}

By doing this, inconsistent APIs could be turned into consistent ones. 
Call joinpoints could then be easily identified with call("% 
ext_libxml::%(...)") and an aspect could weave the error handling policy.

As a positive side effect the external dependencies of your own code 
would be well documented.

>
>
> Do you recommend any other reaction than to call "exit(errno)" or 
> "abort()" in an environment for the programming language "C"?

In a "debug build" aspects could be used to print the call stack for the 
error. I could also imagine an exception-like error handling with 
setjmp/longjmp.

>
> How do you decide if an exception can really be thrown at the affected 
> place in the source code?

This is a hard question. We also discussed this when we wrote the paper 
on turning windows API errors into exceptions. Often an error condition 
is handled by the application. It might be an expected situation. Today 
I would argue that the aspect should turn the error code into an 
exception anyway. Then the application code that uses the API function 
could then catch the exception instead of checking the error code. This 
might cause an overhead, but I would regard this as an optimization 
problem of the weaver. It could be handled by smart static analysis and 
code transformation.

>
> Would you like to add such error reporting to a reusable aspect library?

I would love to do more in this area, but I'm overloaded even without 
doing this. :-( If you have any concrete proposal or ideas, let me know.

Best regards,

Olaf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aspectc.org/pipermail/aspectc-user/attachments/20111207/1697208a/attachment.html>