policy based error handle

policy based error handle

Post by jack hua » Tue, 29 Jul 2003 18:51:47



In "modern c++ design", anderi alexandrescu said you can custom your
class behaviour using policy.
And there I have a question, when deal with error, you can simply
return an error code or raise an exception. But how can i custom the
behavior of the error handling.

e.g.
class error_policy_1 // return error code
class error_policy_2 // raise error exception

can anyone give me some hints or suggestions?
thanx!

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 
 
 

policy based error handle

Post by Richard Smit » Wed, 30 Jul 2003 06:52:04



> In "modern c++ design", anderi alexandrescu said you can custom your
> class behaviour using policy.
> And there I have a question, when deal with error, you can simply
> return an error code or raise an exception. But how can i custom the
> behavior of the error handling.

> e.g.
> class error_policy_1 // return error code
> class error_policy_2 // raise error exception

> can anyone give me some hints or suggestions?

Typically you will be templating some class on the error
policy, for example,

  template <class ErrorPolicy>
  class my_class {
  public:
    void function(); // May need to signal that an error
                     // has occured.
  };

First of all, you'll need to be able to customise the
return type (so it either returns an error code type, or
returns void if the function throws), so:

  template <class ErrorPolicy>
  class my_class {
  public:
    typename ErrorPolicy::error_code function();
  };

So, now how do I write function()?

  template <class ErrorPolicy>
  typename ErrorPolicy::error_type
  my_class<ErrorPolicy>::function()
  {
    if ( !some_implementation_function() )
      // Oops.  It failed
      return ErrorPolicy::signal_failure();

    if ( !another_implementation_detail() )
      return ErrorPolicy::signal_failure();

    return ErrorPolicy::signal_success();
  }

Then we define a pair of functions, signal_failure and
signal_sucess.

  // ErrorPolicy class that returns error codes
  struct error_codes {
    typedef int error_type;
    static int signal_failure() { return errno; }
    static int signal_success() { return 0; }
  };

  // ErrorPolicy class that throws exceptions
  struct error_exceptions {
    typedef void error_type;
    static void signal_failure() { throw std::runtime_error("Foo!"); }
    static void signal_success() { /* do nothing */ }
  };

A real world implementation is likely to need to need to be
able to covert error codes returned by the implementation
into exceptions and vice versa.  The case basic principles
can be used to do this.

--
Richard Smith

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

 
 
 

1. Policy-based design problem (or "How to extend a policy's capabilities")

Hello!

I'm developing a data structure (a kd-tree, btw) for use in very
different applications. My intention is to let the client incorporate
different
algorithms that traverse the data structure through the use of
templated inheritance. The problem appears at the moment of accessing
the data in the structure, because the class provided by the client
doesn't know where it is going to be used, so it cannot directly call
the public interface of the data structure. My solution for this is to
make the client provide virtual function definitions for the functions
in the data structure it wants to use (see code below), so when the
data structure inherits from the class provided by the client, those
functions are overriden and the client uses the ones provided by the
data structure.

I don't really know whether it's the right approach, because it makes
the data structure expose most of its internal data, and forces the
clients to define bogus functions. I mean, what really bugs me is the
data structure having to expose its internal organization (and an
iterator provided by the data structure wouldn't do, because traversal
is algorithm-dependent). Note that a Visitor would have the same
problems of encapsulation.Any suggestions? Thanks!

Pau.

-------------Code----------------

#include <iostream>

template <
   class UserFunctions
 >
class A : public UserFunctions
{
   private:
     typedef A<UserFunctions> TreeType;

   public:
     A() : data_(1234)
     { }
     TreeType *getLeft() { return left_; }
     int getData() { left_ = new A<UserFunctions>; return data_; }
   protected:
     int data_;
     TreeType *left_;
     TreeType *right_;

class MyAlgorithm
{
   public:
     void doSomething()
     {
      [...]
       getData();
      [...]
       getLeft()->doSomething();   <---- This is the interesting recursive part.
      [...]
     }
   private:
     virtual int getData() = 0;
     virtual A<MyAlgorithm> *getLeft() = 0;

int main()
{
   A<MyAlgorithm> a;

   a.doSomething(0);


      [ about comp.lang.c++.moderated. First time posters: do this! ]

2. Lexmark "Quick Pick"

3. Er, handling errors in an error handling routine?

4. Recommended CD-RW Backup Software for W2K?

5. Pointer based memory vs Handle based

6. Another way to soft reset

7. handle-based objects vs pointer-based objets.

8. Using .t64 files with PC64

9. handle based/pointer based memory.

10. Handle-based vs pointer-based memory allocation.

11. Using policy-based smart pointers, part 1

12. Using policy-based smart pointers, part 2