OSDev.org

What would be the most balanced way of handling a intentional or non-intentional bogus application, for example, one that has video memory for 80x25 mode set and there's a try to write below or beyond it (through drivers/libraries)? Note that it's an example and really such drivers should not obey to improper values, but certainly shouldn't totally ignore what to do further, in general.

Would it be better to try to handle exceptions and leave the bogus action without effect and resume? In this case, the most probable would be that the application keeps giving problems since it could rely on the "ignored" operation.

Or would it be better to simply terminate it telling the user both in a technical and in understandable words what has happened and why it was terminated, such as "This application tried to use a space not assigned to your screen to display data and crashed." and then a core/register dump?

~ wrote:What would be the most balanced way of handling a intentional or non-intentional bogus application, for example, one that has video memory for 80x25 mode set and there's a try to write below or beyond it (through drivers/libraries)? Note that it's an example and really such drivers should not obey to improper values, but certainly shouldn't totally ignore what to do further, in general.

Would it be better to try to handle exceptions and leave the bogus action without effect and resume? In this case, the most probable would be that the application keeps giving problems since it could rely on the "ignored" operation.

From a technical and political point of view, for all cases, make the application terminate with a huge red flag. Not just on developer systems but on all systems. If developers know that their errors will be highlighted they'll work around it, otherwise they'll be like "yeah, but on your computer it'd just ignore that error".

From my own point of view, define the behaviour of all functions within acceptable limits and check these inside the trampoline handling. If the values are not acceptable, scream.

Or would it be better to simply terminate it telling the user both in a technical and in understandable words what has happened and why it was terminated, such as "This application tried to use a space not assigned to your screen to display data and crashed." and then a core/register dump?

From a UI developers point of view, don't bother the user. The user is bothered already because the program stopped functioning (see previous point). He should be given a quick way to get rid of the notion of "That application was evil" and to get on with his work, preferably without being forced to change his mindset to "what's happened". I would make a screen with a yellowish tint to it, an exclamation mark for "error" and a slightly greenish button labeled "Close". Also include a "Details...." button that shows the full error report in a copyable form, but make it blend in with the form.

The user should realize so much that the application stopped working (so terminate the application and redraw the screen before showing the error !) but not so much that he has to actively think what to do next (so make the form one that's easily and quickly closed).

I feel that any behavior by the application such as that which you listed is an error in the application. The user needs to be notified so that he or she can notify the person who wrote the application. If you were to just ignore what the application did, then people would start taking advantage of that and you run the risk of breaking compatibility with future versions of your OS. I feel that all applications should be forced to stay with a certain set of guidelines that should always be followed if the application wishes to run.

It depends on wether the faulty condition is handled: all unhandled errors should result in program shutdown.

The problem with this lies mainly in how to communicate errors with the application so that they can not be forgotten.