try /catch Exception missing type

Vaclav_

I am trying to improve my error handling skills. I am somewhat happy with "perror", but that "requires" that the preceding code can report meaningful error messages. Most of the time all I need is "success" message and nothing more specific when error occurs. There is a "feature" in Eclipse IDE which let me "surround" selected code , try /catch is one of them. However, being a greenhorn , I cannot decipher this error message I am getting Exception does not name a type I know what "does not name a type" means , but HOW do I fix it for "Exception"? I did Ask Mrs Google and she did not help much. The extra block in the code is there because I just "surrounded" the perror line. Of course the actual error message is not yet there, until I fix this missing type error. Help will be appreciated. Cheers Vaclav

// returns file descriptor

int memfd = open("/dev/mem", O\_RDWR | O\_SYNC);
if(memfd)
{
	try {
		perror("Failed open /dev/mem ");
	} catch (Exception e) {

	}
	exit(1);
}

Jochen Arndt

Before using a feature you should know about it: Exceptions - C++ Tutorials Then you should realise that catching exceptions makes only sense when functions called inside the try block might throw them. But C standard library functions like perror() do not throw them (because it is a C++ feature, the C standard does not define them). Finally you have to know which kind of exceptions (types) might be thrown. Implement a catch block for each of them. With functions from the C++ standard library, these are std::exception - cppreference.com[^] and derived ones. An example:

#include <exception>

std::ifstream file;
// Enable throwing of exceptions for file
file.exceptions ( std::ifstream::failbit | std::ifstream::badbit );
try
{
// Calling C++ functions here that might throw exceptions

file.open("test.txt");
// Do something with file here
file.close();

}
catch (std::exception& e)
{
cout << e.what() << '\n';
}

Lost User

You cannot catch something that is not a catchable type. And since perror does not throw anything the above code serves no purpose. You can either create your own throwable type or use the <exception> class[^]

Vaclav_

Thanks guys. If I may translate what you have said - it is pretty clear that to use exceptions it has to be "defined" and then implemented / enabled in / by the object throwing it. . Hence missing type error I received. I can see using it in (random) file access, but would it help in writing to hardware I/O via memory map? I am not sure if such error checking would be an overkill - either the I/O is accessible in its entirety or it is not at all. If individual address fails it is not coded by me correctly. Cheers Vaclav

leon de boer

This is a complex thing so lets go thru it. On a Normal O/S, RTOS very few low level functions ever have exception catches they usually simply report it back. The why is simple, the problem it faces is how the exception should report the error, it isn't clear who it should be reported to the APP or the O/S. As an example, early versions of Windows when low level functions raised an exception put up the blue screen of death and silly things on the API could create it. Blue Screen of Death - Wikipedia[^] It actually became a problem because people got sick of rebooting there computer and on the modern versions of windows it is reserved for unrecoverable errors. Almost all the core windows API almost never raises an exception it simply passes the error back to be handled by the caller because part of being able to handle the error is to know what the caller program is which only the caller knows. So basically there is no problem something like an APP raising exception it can rely on the O/S being able to do something sensible with the exception. However if the caller is something like a driver or the O/S itself there is always the problem the thing you are reporting to has already crashed. So in your case file I/O may well be used by a driver so no-one would set it up to raise an exception. Now there are even newer changes in programming to Virtual O/S which started with VMware. There you have a hypervisor program and the O/S or OS's run above the hypervisor Hypervisor - Wikipedia[^] In that enviroment many low level functsions will raise an exception and the Hypervisor will catch them because it is immune to errors in the VM. So in that situation a file IO may well be setup to raise an exception. See the common theme if you are going to raise an exception the thing that catches the exception must be able to continue running despite the error. So the question of if a low level function should raise an exception depends on there being a stable level below it to catch the raised error. What this answer brings in is the concept of protection rings the wiki entry is very Intel centric Protection ring - Wikipedia[