By default, you can not throw exceptions from signals and slots, and if you try it, you get the following message:

Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there.

So, what to do? The answer is simple: Overwrite the function bool QApplication::notify(QObject * receiver, QEvent * event) so that it catches all thrown exceptions. Here is some sample code:

#include <QtGui>
#include <QApplication>
class MyApplication : public QApplication {
public:
    MyApplication(int& argc, char ** argv) :
        QApplication(argc, argv) { }
    virtual ~MyApplication() { }

    // reimplemented from QApplication so we can throw exceptions in slots
    virtual bool notify(QObject * receiver, QEvent * event) {
        try {
            return QApplication::notify(receiver, event);
        } catch(std::exception& e) {
            qCritical() << "Exception thrown:" << e.what();
        }
        return false;
    }
};
int main(int argc, char* argv[]) {
    MyApplication app(argc, argv);
    // ...
}

Of course, you can also inherit from QCoreApplication to get rid of the QtGui dependency, or display a nice dialog box instead of printing the messages to the console, or…

Found at: Stack Overflow: Qt and error handling strategy

The QNetworkAccessManager class is very user-friendly, but it makes asynchronous calls. I was in the need for synchronous calls to handle my HTTP communication, but I did not want the overhead of another thread, so I googled a bit and finally came up with a short call to an event loop that processed the request. Like this:

QNetworkAccessManager * pnam = new QNetworkAccessManager(this);
// the slot was declared at another place
connect(pnam, SIGNAL(finished(QNetworkReply *)), this,
  SLOT(loginFinished(QNetworkReply*)));
QNetworkRequest req(QUrl("http://foo.bar"));
pnam->post(req, postData);

// execute an event loop to process the request (nearly-synchronous)
QEventLoop eventLoop;
// also dispose the event loop after the reply has arrived
connect(pnam, SIGNAL(finished(QNetworkReply *)), &eventLoop, SLOT(quit()));
eventLoop.exec();

This way my user-defined slot for the pnam->finished() signal was called immediately, and I could be sure to have the HTTP reply at the end of this code snippet.

Found here: Qt-Interest Mailing List: QNetworkAccessManager and QNetworkReply, synchronous

…note to myself: Remove a potentially mounted SD card before suspending your SL510, otherwise the kernel gets stuck…

Update: Turned out the SD card was a bit buggy, the driver mostly got a timeout when trying to speak with it.

I wanted to restart my IRC bot on reboot, but I also wanted to have control over it and see its log output, so I wanted to start it inside a screen session. This is nearly trivial, screen -dmS yoursessionname yourcommand is your friend, and you can later on reattach using screen -r yoursessionname.

But what if I want to start multiple commands, each in its own screen window? My first solution used screen -dmS followed by something like screen -r sessionname -X screen; screen -r sessionname -X next; screen -r sessionname -X title "my window title"; screen -r sessionname -X exec "my command line", but it seems that the next command fails in this context, and I ended up with all the mess in one single window.

My next approach (okay, it took me half an hour of reading the manual until here ;-)) was more succesful: I created a session command file which contained screen commands like this:

screen
select 1
title "my window title"
exec mycommand arguments ...

And, voilà, I could paste the single command line into my crontab: screen -dmS sessionname && screen -r sessionname -X source sessioncommandfile