Skip to main content
gamedev.net
🔒 Locked

Exceptions across processes

Started by arthur83 Mar 29, 2007 at 8:49 AM 3 replies 700+ views
Original Post
arthur83
arthur83
I have a question that has been bugging me for quite some time. I have a C++-application that has loaded a DLL, either dynamically through LoadLibrary() or statically as part of the link step. That DLL contains a function that throws an exception and the exception is handled in the application. Is this OK or is it just the worse possible scenario one could imagine? :) Is it alright to throw exceptions across processes?
Cygon
Cygon
DLLs run in the same process as the application that's using them. When you load a DLL, its code is mapped into the address space of the running process and its data is copied into a new memory area in that process.

In windows, you only get a new process if you create one using CreateProcess() or implicitely when you run an executable. Doing anything across process boundaries is pretty darn difficult. Processes are isolated from each other, so eg. memory address 0x123 in process A has nothing to do with memory address 0x123 in process B. To send data from one to another, you'd have to create Pipes, Shared Files, use Window Messages or TCP/IP.


So, as long as you don't plan on using the compiled DLL with a different compiler than the one it's compiled with, you won't have any problems since there are no other processes involved ;)

-Markus-


Professional C++ and .NET developer trying to break into indie game development.
Follow my progress: http://blog.nuclex-games.com/ or Twitter - Topics: Ogre3D, Blender, game architecture tips & code snippets.
Anon Mike
Anon Mike
It can work, but it's dangerous. Especially for C++ exceptions (i.e. thrown with "throw"). If you have different C++ compilers it's very likely that the way they implement exceptions is different and you either will fail to catch the exception or corrupt memory trying to handle it. Even with the same compiler and compiler version you could run into issues similiar to the problems sorrounding memory allocation between DLL's.

It's usually best to fall back to error codes when crossing DLL boundaries.
-Mike
arthur83
arthur83
Cygon: Ahh, that makes sense. I don't really know why I thought that DLLs are spawned as a new process, I just assumed that they did.. :)

Anon Mike: Ofcourse, you right. Non-standard implementation of exceptions is a problem. I'll stick to error codes :)

Thanks!
TheAdmiral
TheAdmiral
You have things straight, which is good, but just for the record:
Exception handling in the usual sense (SEH) doesn't work per process, but per thread. If the DLL creates a new thread and it throws an exception, then it won't necessarily find its way back to the calling procedure.
We could amend this to a degree by using vectored exception handling instead of structured, but it's still a bad idea. Best stick with the error codes [wink].

Admiral
Ring3 Circus - Diary of a programmer, journal of a hacker.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.