Return values, exceptions and error status shouldn't be left unread...

I just lost three hours. Not really the end of the world, but really annoying when you find it was a stupid mistake, combined with badly written code.
I was working on an enhancement for PCT, allowing database connections to be made either with the standard dbName/dbDir/hostName/portNumber attributes, or with just a paramFile attribute. Just a few lines of code to change so that aliases are not broken, a few new test cases, done in half an hour, everything's working. In fact, no, database connections are done differently with background compilations. Spent two minutes correcting this mistake, copied/pasted test case for this task, and boom... Ran tests again, it works... Ran again, boom...
Test cases working half the time when you're working with thread and forked processes communicating with a main server usually mean that you're running into synchronization issues. Just in case, I take "Java concurrency in practice" from my bookshelf, ready to debug this problem. Adding some debug messages in OpenEdge sessions, trying different combinations, re-doing a complete schema of this inter-process and inter-thread communication, I'm unable to find the cause of the problem.
Until I find the "Ha ha" ! My test case is creating a Progress database, and two spawned sessions are compiling programs. But I'm running those sessions with single user connections. And there's NO ERROR HANDLING FOR CONNECTION FAILURES !!! So depending on the mood of my computer, compilation was sometimes done by the first thread, and sometimes by the second thread. No problem for the first thread, DB connection was OK, but the second thread was never able to connect the database (and so compile programs). But I never got a warning or error message saying that it wasn't able to connect...

Result : just lost time, and I have to modify error handling so that DB connections are gracefully handled. Connection failure was handled in OpenEdge, pushed back to the first OpenEdge procedure, pushed back to the Java thread, and there it was dropped silently.

Error status and exceptions are not there to bother the programmer, it's just that something is wrong. So unless you're absolutely sure that you want to skip this error (and you should document that in your code), just let the exception bubble up (with a RuntimeException if possible in Java) or don't use NO-ERROR in Progress if you don't know what to do with it.