Wrapper for File memory mapping destructor
Hello guys,
I'm creating a wrapper object for the C mmap function that maps file on memory. Actually I'm concerned about how to give the user the option to do the unmapping, which is supposed to be automated with the destruction of the obejct, and while it could fail. The way I deal with errors is exceptions, and I read in a book that exceptions in destructors are the worst idea ever, and I totally believe it because it's an open invitation for residues in memory.
How would you guys deal with such a problem? how can I handle this possible unmapping error in the destructor?
Thank you :-)
I'm creating a wrapper object for the C mmap function that maps file on memory. Actually I'm concerned about how to give the user the option to do the unmapping, which is supposed to be automated with the destruction of the obejct, and while it could fail. The way I deal with errors is exceptions, and I read in a book that exceptions in destructors are the worst idea ever, and I totally believe it because it's an open invitation for residues in memory.
How would you guys deal with such a problem? how can I handle this possible unmapping error in the destructor?
Thank you :-)
Either ignore the error or halt the application, I suppose... You're right: never throw in a destructor.
Last edited on
Good question, and I have thought about this, but I don't think there is a trivial solution. The basic problem is that an exception (together with the current execution state) will map to some point of the code where the program recovers and some corrective action. What if you have two exceptions simultaneously? You know where the program should resume with exception A and exception B individually. You also know what are the curative/corrective actions that should be performed before resuming. But what happens if you have both A and B and who will decide where the program will recover and how it will recover? This is the real problem. The language mechanics are the smaller issue.
I think that a very basic question: What happens when I cannot close/discard a resource that I did acquire.
I'd say you can't do much: Log it to a file for later trouble shooting. Better not disturb the 'shutdown' procedure. The error might even be that the resource is already discarded.
I'd say you can't do much: Log it to a file for later trouble shooting. Better not disturb the 'shutdown' procedure. The error might even be that the resource is already discarded.
Ah... this is very frustrating! There's not really a way to detect this!
I guess I'll just create a function for dismounting and put it in the destructor and recommend using this function manually to dismount the mapping. If the user doesn't use this function, then he has to take the consequences of unmapping it manually!
Thanks for the answers guys, at least I know now I'm not that noob in C++ :-P
I guess I'll just create a function for dismounting and put it in the destructor and recommend using this function manually to dismount the mapping. If the user doesn't use this function, then he has to take the consequences of unmapping it manually!
Thanks for the answers guys, at least I know now I'm not that noob in C++ :-P
@coder777
The second concurrent exception may not be directly related to releasing resource. For all you know, it may be thrown by vector.at. True, it will be in destructor, but this is very broad category of processes. It may not even result in a leak directly. The same problem appears if you intend to rethrow the exception caught in a catch statement, but the statement itself generates an exception. I think it is conceptually unexplored topic and it has to be dealt with scientifically. Admittedly, the result may be your very conclusion.
P.S. In fact, there may be some conclusions done. I haven't searched yet.
The second concurrent exception may not be directly related to releasing resource. For all you know, it may be thrown by vector.at. True, it will be in destructor, but this is very broad category of processes. It may not even result in a leak directly. The same problem appears if you intend to rethrow the exception caught in a catch statement, but the statement itself generates an exception. I think it is conceptually unexplored topic and it has to be dealt with scientifically. Admittedly, the result may be your very conclusion.
P.S. In fact, there may be some conclusions done. I haven't searched yet.
Topic archived. No new replies allowed.