void DllInjection::injectCode() // should i turn all this into throws as well :/?
{

	if ((processHandle = OpenProcess( PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION | PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_VM_READ,0,processID)) == NULL)
	{
		_InjectionStatus = CREATEHANDLE_ERROR;
		return;
	}
	if ((memoryAddress = VirtualAllocEx(processHandle,NULL,wcslen(dllName.c_str()),MEM_COMMIT,PAGE_READWRITE)) == NULL) // check third argument, it wouldn't let me use strlen() because it doesnt deal with wide chars
	{
		_InjectionStatus = ALLOC_ERROR;
		return;
	}
	if ((WriteProcessMemory(processHandle, memoryAddress, dllName.c_str(),sizeof(dllName),NULL)) == 0)
	{
		_InjectionStatus = WRITEPROCESS_ERROR;
		return;
	}

	_LoadLibraryEx procAdd = (_LoadLibraryEx)GetProcAddress(GetModuleHandle(L"kernel32.dll"), "LoadLibraryEx");
	if ((CreateRemoteThread(processHandle, NULL, 0, (LPTHREAD_START_ROUTINE)procAdd, (LPVOID)memoryAddress, 0, NULL)) == NULL)
	{
		_InjectionStatus = CREATETHREAD_ERROR;
		return;
	}
	_InjectionStatus = SUCCESS;
	return;
}

ok now here is my dilema....How do i know what i should use c++ exceptions for vs. keeping track of an error code??

for example..in the above code if i call that function with my object,then THROW back to the caller,which is main, THE CALLED function that threw the object never knows it had an error. I think i might be confused on when i am suppose to use exceptions vs keeping track of an objects state/error codes. -thx

I don't really understand your question...

The decision between throwing in error-cases or returning a status code is a design decision... advantage of trowing exceptions is that if you don't catch them, the program will crash, where if you just return a status code (e.g. FALSE) the caller can ignore this status code, producing undefined results. If you are a consist programmer this should not happen though (and there are code annotations that can spot cases where you forgot to check a return value.. google if you want to know more ;))

In your case I would just alter this function to return a boolean, especially if you're not very fluent in C++ yet. In any case, you should stick to a consistent approach, don't in one case throw exceptions and in a similar function return an error value.

I don't understand your comment "the called function ... never knows it had an error". Even if it knew, what would it do about it? It really doesn't have to care.

The caller requested something to be performed... if there was an unrecoverable failure, the caller should deal with that.

Edited 6 Years Ago by thelamb: n/a

You sent me a PM, please don't do that.. post here:

so in other words...c++ exception handling should only be used when a program will/can crash because of an error? in this case i should just return an error code if the program is unable to perform the requested operations?

No: I said 'if you don't catch an exception the program will crash'. If you catch it, it will not crash.
What I was trying to say with this is that you basically force yourself to do error checking if you use exceptions - you don't _want_ your program to crash if something small goes wrong.

The downside of excessively using exceptions is readability of code... because you will need try{ } catch ( ... ) { } blocks everywhere.. on the other hand, a lot of if( something == false ) can also be cluttering.

This article has been dead for over six months. Start a new discussion instead.