<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi!<br>
<br>
You raised a lot of interesting points. Find my comments below ...<br>
<br>
On 11/29/2011 01:41 PM, Markus Elfring wrote:
<blockquote cite="mid:4ED4D2EF.1000709@web.de" type="cite">
<blockquote type="cite">pointcut void_function() = "void
...::%(...)";
<br>
advice execution("% MyClasss::%(...)" && !void_function()) :
...
<br>
<br>
We have used this in an example in which we transformed C-style error
codes
<br>
into exceptions.
<br>
</blockquote>
<br>
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.
<br>
<br>
1. Functions with an interface style like strcpy() forward an input
parameter as their output.
<br>
<br>
2. There are a few functions where the meaning of a successful
execution depends completely on the passed input parameters.
<br>
Example: DispatchMessage();
<br>
<a class="moz-txt-link-freetext" href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms644934.aspx">http://msdn.microsoft.com/en-us/library/windows/desktop/ms644934.aspx</a>
<br>
<br>
3. An API documentation might be unclear if an error predicate should
be checked.
<br>
<br>
4. An output parameter should be checked instead of a value from the
function return type (because it might be "void").
<br>
</blockquote>
<br>
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.<br>
<br>
What do you think about the following design? ...<br>
<br>
For each external library that you use in a project define a namespace,
e.g. ...<br>
<br>
namespace ext_libxml2 {<br>
...<br>
}<br>
<br>
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 ...<br>
<br>
namespace ext_libxml2 {<br>
// normal case<br>
using ...;<br>
<br>
// special case: normally in libxml2 all errors are signaled by -1 as
return code. Here it can be positive.<br>
int xmlValidateName (const <a
href="http://xmlsoft.org/html/libxml-xmlstring.html#xmlChar">::xmlChar</a>
*value, int space, int &error_code) {<br>
error_code = ::xmlValidateName(value, space);<br>
return ((error_code != 0) ? -1 : 0);<br>
}<br>
}<br>
<br>
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.<br>
<br>
As a positive side effect the external dependencies of your own code
would be well documented.<br>
<br>
<blockquote cite="mid:4ED4D2EF.1000709@web.de" type="cite"><br>
<br>
Do you recommend any other reaction than to call "exit(errno)" or
"abort()" in an environment for the programming language "C"?
<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:4ED4D2EF.1000709@web.de" type="cite"><br>
How do you decide if an exception can really be thrown at the affected
place in the source code?
<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:4ED4D2EF.1000709@web.de" type="cite"><br>
Would you like to add such error reporting to a reusable aspect
library?
<br>
</blockquote>
<br>
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.<br>
<br>
Best regards,<br>
<br>
Olaf<br>
<br>
</body>
</html>