Glenn Schrader wrote:
Well, I hacked up a version that used status flags to return the open failure rather than an exception and it works find. Of course if there ever was any out-of-memory condition (etc) then it would just terminate but I view that as just part of the contract you get when you turn exceptions off then use an API that might throw. In practice this level of functionality is usable. On a more philosophical note, I don't think that exceptions are the "right" way to implement this. Exceptions are best used to signal exceptional conditions and not as a way to control normal program flow. An open failure, rather than being exceptional, is the most commonly expected case since only one process will actually not throw. My $0.02.
That was the case for the original Shmem (Interprocess parent) library but in the review Boosters decided that exceptions were the way to go. The problem with out-of memory is that getting out of memory in the shared memory segment is more common than out-of-memory in the heap. And crashing the program when the shared memory is full is not a good idea, IMHO. What I could do is to add non-throwing overloads, but I don't know when I'll have time to do it. I would want to make the whole library compatible with disabled exceptions (including containers and other classes). I know someday I'll do a non-throwing version of Interprocess because I not a big fan of exceptions, but I don't know when ;-) Regards, Ion