Move error cleanup code to C++?

[stroiman]

Looking at the code to handle errors (which I mentioned should probably also contain a v8 Value).

I also notice that the conversion itself does a bit of cleanup.

func newJSError(rtnErr C.RtnError) error {
	err := &JSError{
		Message:    C.GoString(rtnErr.msg),
		Location:   C.GoString(rtnErr.location),
		StackTrace: C.GoString(rtnErr.stack),
	}
	C.free(unsafe.Pointer(rtnErr.msg))
	C.free(unsafe.Pointer(rtnErr.location))
	C.free(unsafe.Pointer(rtnErr.stack))
	return err
}

I was wondering if it would make sense to have a class in C++ to represent this information, so it would be a simple matter of calling

void ErrorDelete(RtnError *err) {
   delete RtnError;
}

Maybe the type could take (my C++ is probably wrong, but I'm sure you get the idea).

class RtnError {
public:
  int msgLen;
  char* msg;
  RtnError(  Local<Value> Message,   Local<Value> Location,   Local<Value> StackTrace) {
    this->msgLen = Message->Utf8Length2();
    this->msg = new char[this->msgLen];
    Message->WriteUtf82(this->msg);
  }
  ~RtnError() {
    delete this->msg;
  }
}

More cohesive - what changes together, stays together.

[tommie]

Adhering to RAII would be nice there, indeed.

[stroiman]

On a somewhat similar topic - so I just add it to this thread instead of a new

  RtnString rtn = {0};

And sometimes it says

  RtnValue rtn = {};

I was completely unfamiliar with this syntax, but apparently it's a C++11 thing (my C++ experience predates C++11) - but it initializes the struct with zero or default values.

But again, wouldn't it make sense to make those types into C++ classes with a default constructor that initializes the values to zero? I'm unsure now much refactoring is necessary - but I see quite a lot of duplicated code converting a V8 value into a struct to return to the Go caller.

[stroiman]

Exactly. RtnValue itself embeds a value and an error - also bridging into Go's errors as values, so if it contains values, not pointers, that themselves have default constructors, they should also initialize to zero, and also have proper destruction semantics

[stroiman]

Combining an Error with a value could be a template, but let's not get too crazy ...

[stroiman]

Anyway - I am looking into this part of the code for the import resolution, where I need to operate on a FixedArray and much of the code, for dealing with Handle<>s are implemented for Value - but they both share Data as a base class. As far as I can tell, Data is everything that needs a Handle<>.

[stroiman]

So I'm wondering how much of the code to transfer Values between Go and C++ can be written to work on a higher level of abstraction - and obviously I can't help wondering if some things could be done in a more clever way :)

[stroiman]

Ohhh - but the data that is transferred between Go and C++ must be valid C types - so no classes.

I'd probably still want to move the delete calls to C++ code still to increase cohesion - if there are 3 pointers to delete, that is close the where there are 3 pointers defined.