update swig on windows

winx64/bin/swigwin-4.0.0/Examples/python/exceptproxy/example.i

@@ -0,0 +1,103 @@
+/* This is a rather sophisticated example that illustrates exception handling,
+   templates, and proxy classes. 
+
+   (i) The %exception directive is used to attach exception handlers
+       to specific methods.
+
+   (ii) Exception classes are automatically converted to proxy class
+       objects.
+
+   (iii) The %template directive is used to expand the templates
+*/
+
+%module example
+
+%{
+#include "example.h"
+%}
+
+/* Define some exception handlers for specific methods.   In
+   the header file, the enqueue method throws FullError and
+   the dequeue method throws EmptyError.  Since we don't
+   want to define an exception handler for everything, we
+   simply write a handler for each method individually.
+
+   Note: the *::enqueue syntax means that we simply define
+   the handler for any class with this method defined.
+*/
+
+%exception *::enqueue {
+   try {
+      $action
+   } catch(FullError& e) {
+     FullError *ecopy = new FullError(e);
+     PyObject *err = SWIG_NewPointerObj(ecopy, SWIGTYPE_p_FullError, 1);
+     PyErr_SetObject(SWIG_Python_ExceptionType(SWIGTYPE_p_FullError), err);
+     SWIG_fail;
+   }
+}
+
+/* Some notes about the code above:
+
+   (0) $action gets replaced with the actual method call.
+
+   (1) We are going to return a copy of the exception object (FullError)
+       to pass back to the Python interpreter.  This is why the copy
+       constructor is being called.
+
+   (2) The SWIG_NewPointerObj() call automatically wraps the exception object
+       into a proxy class.  The SWIGTYPE_p_FullError is the type-descriptor
+       used for type checking.  The "1" indicates that Python will have
+       ownership of the resulting object.
+
+   (3) The PyErr_SetObject call sets the Python exception.  However,
+       the SWIGTYPE_p_FullError->clientdata reference may not be
+       obvious.  This is actually the Python proxy class object
+       for FullError.  Recall that in Python, exceptions are defined
+       as classes.  Therefore, this works perfectly as the argument to
+       PyErr_SetObject()!   A neat trick perhaps.
+*/
+
+/*
+  Python classes that are used as exceptions need to be subclasses of the
+  "Exception" class, and so SWIG needs to know which wrapped classes may be
+  used in this way.  You can explicitly tell SWIG this by using
+  %exceptionclass.  SWIG will implicitly set this feature for classes which
+  appear in a throw declaration, but it's not a problem to explicitly
+  mark such classes as well.
+
+  This is a Python requirement - if you fail to mark such classes with
+  %exceptionclass you may see 'interesting' behaviour on the Python side.
+*/
+%exceptionclass EmptyError;
+%exceptionclass FullError;
+
+%exception *::dequeue {
+   try {
+      $action
+   } catch(EmptyError& e) {
+      EmptyError *ecopy = new EmptyError(e);
+      PyObject *err = SWIG_NewPointerObj(ecopy, SWIGTYPE_p_EmptyError, 1);
+      PyErr_SetObject(SWIG_Python_ExceptionType(SWIGTYPE_p_EmptyError), err);
+      SWIG_fail;
+   }
+}
+
+/* Grab the original header file */
+%include "example.h"
+
+/* Instantiate a few templates */
+
+%template(intQueue) Queue<int>;
+%template(doubleQueue) Queue<double>;
+
+
+%inline %{
+// The -builtin SWIG option results in SWIGPYTHON_BUILTIN being defined
+#ifdef SWIGPYTHON_BUILTIN
+bool is_python_builtin() { return true; }
+#else
+bool is_python_builtin() { return false; }
+#endif
+%}
+