C / C++ / MFC
|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[^]
You are mainly working on the Pi and on ARM processor they call it EXCEPTION LEVELS and we shorten it to EL. This is the setup on Pi3 which runs Cortexa53 cores it has EL0, EL1, EL2, EL3
CortexA-53 Exception Levels[^]
You will note they describe what parts of a system they expect to be running at what level
EL0 = Applications.
EL1 = OS kernel and associated functions that are typically described as privileged.
EL2 = Hypervisor.
EL3 = Secure monitor.
Now just to put that in perspective when you run your Raspbian linux it only uses EL0 & EL1 there is just a pass thru bootstub for EL2 & EL3 so you could say it doesn't use the CortexA53 to it's full capabilities. The reason why is that there are lots of processors out there that don't have it's protection level abilities and it would require a special version of linux to support it.
Now specifically in your case because you are writing code inside linux, your file i/o will be EL1 but your app will be EL0 ... there is a complex issue ... you are trying to make EL0 handle EL1 errors and it doesn't have the permissions to do so. It requires a very complex setup with callbacks that I won't go into unless you want.
Hopefully you see the answer to your question gets incredibly complex.
In vino veritas
General News Suggestion Question Bug Answer Joke Praise Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.