Error handling (Linux, Qt 5.15)
-
@JonB said in Error handling (Linux, Qt 5.15):
We have tried to explain to you that it has nothing to do with Qt libraries or Qt Creator.
Maybe you could/should auto-save your valuable data on a regular timer, when the application is in a safe and consistent state?Well, actually, as we see QT can handle these severe errors, but on the primitive level. So it certainly has something with QT library.
As for constant saving of important data, yes is is also the way, but it is not as elegant as try/catch in Delphi/CBuilder during every attempt to do sometning with memory. I think memory manager must know the limits of allocated memory.
@qAlexKo said in Error handling (Linux, Qt 5.15):
Well, actually, as we see QT can handle these severe errors, but on the primitive level. So it certainly has something with QT library.
No, it does not. Tried to explain multiple times it has nothing to do with Qt, but you just keep repeating it does. Your understanding of what Qt is is wrong. Qt is not a language. And C++ does not behave the way you would like it to, but that is not a Qt issue.
but it is not as elegant as try/catch in Delphi/CBuilder during every attempt to do sometning with memory
If you really feel this strongly about the way Delphi/CBuilder handles this (which btw only started out as checking for a null pointer, which I would have thought is a minor issue compared to all the other things which can go wrong with pointers) then I would suggest you stick with it to provide exactly what you want. No point switching to a different C++ compiler and then bemoaning that it behaves differently from the original one whose behaviour is what you require.
I think memory manager must know the limits of allocated memory.
Don't know what this means.
If you think that all C++ compilers/the C++ language ought behave the way Delphi/CBuilder does for this issue I suggest you write to the C++ standards committee and ask them to change the language's behaviour to your requirement.
-
@qAlexKo said in Error handling (Linux, Qt 5.15):
Well, actually, as we see QT can handle these severe errors, but on the primitive level. So it certainly has something with QT library.
No, it does not. Tried to explain multiple times it has nothing to do with Qt, but you just keep repeating it does. Your understanding of what Qt is is wrong. Qt is not a language. And C++ does not behave the way you would like it to, but that is not a Qt issue.
but it is not as elegant as try/catch in Delphi/CBuilder during every attempt to do sometning with memory
If you really feel this strongly about the way Delphi/CBuilder handles this (which btw only started out as checking for a null pointer, which I would have thought is a minor issue compared to all the other things which can go wrong with pointers) then I would suggest you stick with it to provide exactly what you want. No point switching to a different C++ compiler and then bemoaning that it behaves differently from the original one whose behaviour is what you require.
I think memory manager must know the limits of allocated memory.
Don't know what this means.
If you think that all C++ compilers/the C++ language ought behave the way Delphi/CBuilder does for this issue I suggest you write to the C++ standards committee and ask them to change the language's behaviour to your requirement.
@JonB said in Error handling (Linux, Qt 5.15):
If you really feel this strongly about the way Delphi/CBuilder handles this (which btw only started out as checking for a null pointer,
Look as an Access Violation handling can be realized withing a function (Linux QTcreator). My example looks not very pleasant but QT developers probably can make macros to make it look good. Yes, in the business of handling first were logjumps, then try/catch followed.
jmp_buf ape; void AcessViolationHandler(int signum) { _ML.p("AcessViolationHandler is called"); //this is my logger // Do stuff here then return to execution below longjmp(ape, 1); } //------------------ void Tmq_blf::on_actionAccess_Violation_tst_triggered() { struct sigaction act; struct sigaction oldact; memset(&act, 0, sizeof(act)); act.sa_handler = AcessViolationHandler; act.sa_flags = SA_NODEFER | SA_NOMASK; sigaction(SIGSEGV, &act, &oldact); int i = 10, *j=NULL; if (0 == setjmp(ape)) { *j = i; sigaction(SIGSEGV, &oldact, &act); } else { sigaction(SIGSEGV, &oldact, &act); /* handle SIGSEGV */ } QMessageBox bx; bx.setText("The app survived AccessViolation and continue to run"); bx.exec(); } //------------------