Catching memory access violation
BlitzMax Forums/BlitzMax Programming/Catching memory access violation
| ||
| Any way to catch a memory access violation when app is running and encounters with a null object for example I want to send it to a 'crises Rooting section' In other words, when an application crashes I want to be able to send the process to a save section so i can recover from the crash later. Like Saving map in an editor. |
| ||
| Hiya, Hardcoal, have you looked at the Try Catch EndTry Would that fit in with what you want to do? |
| ||
| thanks but what im looking for is a process you declare on the main of your project like interrupt. |
| ||
| There are a couple of things here that spring to mind... How come you want to handle a memory access violation via exception handling ? This is kind of pointing to 'incomplete' error checking code. Your code should be written in such a way so that exception doesn't get raised in the first place. I'm trying to think of a scenario ( as a programmer ) where you would want to handle an memory access violation via an exception handler and I'm coming up blank. Exceptions are a 'last resort' method which are at the OS level but raised by the hardware. Exceptions should be thought of as 'something serious has gone wrong with your code' safety net and your code should really be written in such a way to make sure the exception doesnt happen in the first place. Think of an exception is a safe guard for the system, not for your code. For eg if you try to access an invalid memory address or do a divide by zero, these kind of errors should be checked and handled via your code, not via an exception. Of course exception handling via code does have its place - most definately - but I'm thinking maybe you're handling the symptom ( the exception is raised ) instead of handling the fault - check and handle errors via code? Whats the bigger picture of what/how you want to do it that way? maybe we could throw some alternative ideas into the mix. EDIT:- maybe you're writing a debugger for other code? |
| ||
| Isn't "memory access violation" like a null pointer exception? Surely at the point you've tried to access memory outside of your application scope, any actions by your program after that are undefined? Exception != MAV If you have MAVs then you need to fix your program. |
| ||
| Hiya Brucey, Yeah thats correct, even worse if somehow the instruction pointer itself is causing the mav. There are more than likely language implementations and possibly some os level tricks/techniques that you can use to handle it via an exception, but usually its just not... the done thing, and these things are normally 'prevented' rather than 'handled'. |
| ||
| Ok guys. Got the point. I guess i didnt know how sever mav's are, and what exactly they mean. Offcourse im doing all i can to prevent them. Although its almost impossible to have a 100% bugless App. But.. When im running compile in debug mode How come the error is catched by blide and reported? Doesnt that means that a side process is catching it? How does some applications recovers from a crash. After all, I didnt invent this case... So its not so weird to ask such a question after all. Maybe they use a flag in the app to alert that it wasnt closed properly.. |
| ||
| Although its almost impossible to have a 100% bugless App. You can create 100% bugfree code - at least in the sense that you can handle all errors should any occur. Its not as difficult as you may think, however it requires careful and correct planning and handling. Without going into too much details - Exceptions are generally dealt with and raised in the language implementation and your own code, failing that then the cpu/OS will raise an exception - if it notices the error of course. In debug mode BRL have implemented some checks that will raise an exception if something obvious is wrong with your code during runtime ( array bounds, null pointers etc ). These checks are created in the assembly output of the compiler and any failures are implemented and handled via 'Max and some C ( the Blitz runtime ). If you want the same functionality within a release build then you would simply do the same checks yourself ( in 'Max obviously as opposed to assembly ) and Throw an exception that you could Catch and handle yourself. ie - checking for null pointers and/or checking for a zero value numerator variable within the code that is called within the Try/Catch - any failures or invalid values and you use Throw. Failing that if you dont do the checks and fail to handle invalid values correctly then you will get undefined behaviour - of which at the very best outcome is the cpu and OS will handle the error ( usually with a popup window ) the worse case is anyones guess as literally anything can and will happen! ADDED- You don't have to use exceptions to handle incorrect pointers, array indices out of range etc, you can write code to react according to the invalid variable/data, the important part is that you handle it - it doesn't matter how. |
| ||
| Maybe they use a flag in the app to alert that it wasnt closed properly.. You can handle that by using a file - it doesnt even need to contain anything - just needs to exist. For eg.. when the app is started check if the file exists, if not then the app was closed normally - so create the file and proceed as normal. When the app is closed properly then delete the file. Ultimately - should the file exist any time the app is started then the app wasnt closed properly. |
| ||
| As highlighted in this other thread: http://www.blitzbasic.com/Community/posts.php?topic=101539#1206478 ...in release mode, BlitzMax doesn't behave in a predictable fashion at all when things go wrong with memory accesses. You can only really rely on exceptions that were thrown by the Throw statement to exist. Exceptions aren't the same thing as errors. An error is a problem with the program's design, and needs to be fixed by changing the program itself. An exception is just an unusual situation possibly reflecting e.g. a problem with input data, that the program/procedure can recognise and hand off to someone else. (Oversimplified: whole books and theses have been written about this.) You can create 100% bugfree code - at least in the sense that you can handle all errors should any occur. Worth pointing out that in a HM-typed language, errors simply don't occur at runtime: the compiler can prove it. Of course this is not the same as saying the program was designed correctly in the first place or actually does the right thing. |
| ||
| When you have a really large complex project even large companies cant get to 100% bugless so easy. But i will sure strive to reach pretty close. Either way i will perfect my code to near perfection slowly i believe. I was just looking for a safe net |
   |