@moellney said:

Anyway, my intention for this discussion was not to start a discussion about pro/contra of exceptions, though.

Yup, sorry. One of the downsides of exceptions is it's almost impossible to talk about them without talking about whether they're worth it.

My question was more, if there is an established design concept

Well, as the link you originally posted says - exceptions thrown across connections are undefined behavior. This in practice means that anything that can be used in a Qt connection should not throw exceptions. This means any method of a QObject derived class, any free standing function, lambda or functor you intend to use in a connection. So yes, you should mark all of that noexcept and generally the more localized your exception handling is the better/safer. As for threading - exception handling is only supported by QtConcurrent and QException derived exception types. Anything else is unspecified, so basically a no-no.
If you build models/backend around exceptions don't just keep them local and make sure you catch them before crossing into the Qt land.

I'm still looking into details about the STL

Yeah, this is one of the reasons I wish noexcept had different defaults :( Implementations like this make things slow by default, which is very sad for C++.

@JonB said in About exception:

/EHa

What /EHa does is chaniging the definition of an exception, extending it, wrapping system level errors as exceptions. This is non-standard and AFAIK MSVC specific.

I would stay as far away from it as possible.

@CJha said in QComboBox and smart pointer conflict?:

But in any case I would like to make sure that it is destroyed before the application exits.

In general this is a good approach. When you write clean code all resources should be freed by your own application (typically RAII in C++). However, when your application closes the OS will free all memory belonging to the application and removes all file handles of the application. Especially in complex applications it can take quite a while to clean up everything in order. In those cases it is a lot more userfriendly to just exit without the clean up. So, don't worry too much about clean up. Still, you should understand why this happens and how it can be avoided.

@JonB yes the path to the .dll ist right - the weird thing is that one function works fine but the others won't

The error I am receiving is: Unkown error.

@JKSH Yes, I created two simple console applications and added required libraries to them. Compiler keys are identical. I checked carefully. A one project have a mistake, and another doesn't have For example, a project with subprojects have this error, but QT Widgets does not have (but not always). Heisenbug?

@VikramSamy said in QT5 application crashed after running for some long time.....:

so my question which is the better, use as my original code and delete the Qstringlist somewhere, or create the QStringlist in the stack and let it get destroyed by itself after getting out of scope as above ??

There is no generic answer to this question as it simply depends on the use case. If you only need this list in that method then you simply allocate it as local variable. Having it as member variable in the class is only needed if you need the list at several places in your class.
By the way this is not heap allocation:

private: QStringList TableMessages; QStringList TableMessagesNOT;

@jsulm there was in fact a problem with window3d() that MinGW didnt complain about! Thanks!
@JonB no I had commented out only up to the second screenshot, so that's why this was the problem.
And about the second issue, to be honest I adapted the constructor from an older version of the application and it also had &argc. At one point I also noticed it and now I tried out both and both work.

Can you test whether a more recent version of Qt still has that problem ?

The Qt 5.9 series is at the 5.9.6 and 5.11.1 being the current version.

@Petin, does your program run correctly if you don't throw an exception?

Forgive me if this doesn't help, but it's what I'm thinking.

I'm not sure if this will even work (unsure if you can swap sources) like this on width changed... but onCompleted should be ok?

It may get you experimenting / thinking differently to get a solution.

http://doc.qt.io/qt-5/qml-qtquick-loader.html#source-prop

Loader { id: container anchors.fill: parent // setSource on Loader Component complete Component.onCompleted: { doSetSource(); } } Connection { target: container; onWidthChanged: { doSetSource(); } } function doSetSource(){ if(container.width < 320) { container.setSource("ViewSmall.qml"); ...

Hello Sebastian,

I am seeing the same problem. The last frame on the stack after a crash points to qwebengine core

qt5\qtwebengine\src\3rdparty\chromium\base\process\memory_win.cc @ 41 but its actually capturing various other exceptions from our application.

Were you able to solve the problem?

Thanks!

@kshegunov ,

agree with what you have written.

I think , I was in rush to reply to the one who objected on using the pointer to a container structure.

So I went on and hoping to convey the idea of me doing it rather than being careful in writing the correct way.

All the best to you Kshegunov.

Indeed, don't forget to provide a minimal compilable example. That will help greatly.

@ChrisW67

Thank you for you help.
Probably the thing is, QSerialPort has a problem to work in a new thread.

I can handle the other QObject in a new thread very well, and the exception only happens when the Object contains QSerialPort.
Also, in my last post, I actually never user QList, although Qt tells me something wrong with QList.

I have given up on working serialThread. QSerialPort does work good in the main thread.