Avoid application crash when error occurs
-
Hi,
I'm wondering when some errors occur Qt application is crashed.
Let's suppose that when user do something that leads to application crash I want that this operation wasn't executed and application wasn't crashed. Do I have to predict all possible crashes and implement some kind of a "if - else" statements in these lines of code?
As example if application should get image but instead of that user put .mp3 file.
What is the best way to avoid such problems? -
@Please_Help_me_D said in Avoid application crash when error occurs:
Hi,
I'm wondering when some errors occur Qt application is crashed.
Let's suppose that when user do something that leads to application crash I want that this operation wasn't executed and application wasn't crashed. Do I have to predict all possible crashes and implement some kind of a "if - else" statements in these lines of code?Yes. That's why testing, unit testing, code checking tools (valgrind, asan) are so important.
If a library throws exceptions (Qt does not), you can use try-catch blocks to catch such crashes.
But in general a crash is good. When an application crashes you know immediately that something went wrong (it's impossible to miss a crash! Silent errors are much worse), you can easily get a stack trace and debug it quickly.
As example if application should get image but instead of that user put .mp3 file.
When you write your code, you should try to write it in a way that it won't crash, of course - make sure that user is not allowed to do "bad" things. If they do something unexpected (like wrong file type), show a popup message and ignore the file.
What is the best way to avoid such problems?
I don't think it's appropriate to generalize here. What you ask about is a big and complex set of issues. There are hundreds reasons for an app to crash (your bug, 3rd party library bug, out of memory, overflows, bad index access on a list, driver issues etc.) and each needs to be handled appropriately (bugs need to be fixed, bad user actions corrected or ignored and so on). And you should always keep in mind that the app should remain usable and convenient to the user.
-
@Please_Help_me_D I wonder what answer you were expecting? If there was some magic compiler flag for "--enable-no-crashong-and-always-do=right_thing" then it would be on by default, and no software would ever crash or do the wrong thing. As the programmer, you have to write a program telling the computer exactly what you want it to do, and then means being responsible for thinking about all the various ways something might happen besides what you hope for in the best case. In general, most of a mature and well written program will be about handing things going wrong in or unexpected or unusual ways because there's usually only one path where things go exactly right but zillions of various interconnected ways for things to go wrong at every step.
open a file : Can be a success. Can try to open a file that doesn't exist. Can try to open a file that exists but you don't have permissions to open. Can try to open a file that exists and you have permissions but there is an I/O error. Can try to open a file that is on a remote system so it would eventually work but it's over a very slow network link so you need to time-out. Can open a file but it turns out to be empty. Can open a file and it's a format other than what you expected. etc., etc., etc. Some programs will need to care about the differences. Others can just crash, maybe giving a simple error message first. There's no universal right answer for the behavior.
A simple utility like cat can just safely crash if it fails to read something, doesn't consider a zero byte file an error, and never cares about the format of the data and wouldn't crash if a .jpg named file actually had mp3 music in it.
Something like Windows Explorer should never just crash, should always recover if it fails to read something while you are browsing files, and needs to have sane behavior if it sees a file named .jpg, and tries to read it to show a thumbnail but it can't read the image. It can't block the whole UI for minutes if you open a folder on a slow network server.
Something like ffmpeg converting a jpeg sequence to a video file can wait all day for opening the file over a slow link, so it's not an error to block for a long time since it has nothing else to do. But it should halt if the jpeg is not a valid jpeg file and do no further work.
Three different programs, three completely different sets of expectations from a user about what constitutes good behavior.
-
@wrosecrans said in Avoid application crash when error occurs:
I wonder what answer you were expecting? If there was some magic compiler flag for "--enable-no-crashong-and-always-do=right_thing" then it would be on by default, and no software would ever crash or do the wrong thing.
Seems to me there is no such compiler flag... unfortunately :)
Thank you for detailed explanation!
