Which, as stated before, didn't look like one.
True, the midlet would die on me when the GPS was forcefully disconnected ... but isn't that what midlets do? You take away their bluetooth connection, they die, right?
Wrong, apparently. And it wouldn't make sense, too - why should an application die just because of lost bluetooth connection?
For some reason, i started thinking about it yesterday, spent a good hour googling for the explanation and found none, so i finally gathered my courage and posted a question on SonyEricsson developer forums.
First answer solved my problem.
Two lessons to be learned here, apart from the "if google doesn't know that a problem exists, there's something wrong with the problem"...
First, Exception isn't the root of all that can go wrong. Throwable is. Replacing my Exception handling code to handle all Throwables revealed that there actually is a Throwable being thrown, and it's an OutOfMemory one.
Which also explained why the application died - when an OutOfMemory condition happens, dying is the sane thing to do. (Really. Trust me on this one.)
And second... well, not really that much of a lesson, except maybe "don't trust (foreign) code, even if you read it and thought that it's fine". That OutOfMemory was caused by a loop that continuously read from the bluetooth link and saved results into a ByteArrayOutputStream (which was rather stupid thing to do in itself, but oh well), until it found a newline.
Except that when the link died, stream did not vanish (that was handled, but honestly, what would you think if a stream just vanished from under your program? i wouldn't write something like that, but when i was reading it, it looked like proper error handling) and instead started reporting "end of stream". Which it did by returning -1.
The loop happily filled the byte array with -1's and happily ran out of memory in the middle of doing that.
Simple bug, simple fix.
Once you realize that it is a bug and not a status quo.