In some peculiar cases there will be an error thrown somewhere in the Blackberry modules that were invoked from your coed, but the error will never return to you, even with a try-catch block set. The stack trace of the error will be printed to the console, your process will be terminated and an error message will pop up on the device/simulator screen with: Uncaught exception: and the exception name.
An example for this is the Controlled Access Exception. When trying to open a file that is access controlled, even a specific catch for this error it will not matter, the process will be killed and the error window for uncaught exception will pop up. The best practice is of course to check for access control before reaching for the file, but it still doesn’t make sense to have it swallow the error and kill the process instead of bubbling it up. Also, for the access control it’s pretty straight forward, but now I have encountered it again, with a java.lang.Error exception and the process gets killed… java.lang.Error is slightly less informative than ControlledAccess 
I’m giving part of the stack trace below, from the trace it is clear that this happens when trying to load an encoded image resource. However it fails on some internal function: getIconOffset. Unlike ControlledAccess, so far I was unable to find documentation about it. And this is where I am right now, I will update once I have some more info and hopefully a fix…
Solution! In order to explain what the problem was I’ll give a short description of how we have the application set up. We have the main entry point which starts on start up and we also have an alternate entry point that shows up as an icon to allow users to access the application. What happened was, we have the application icons set in the alternate entry point, one marked as rollover. This icon file was also included in the cod file and loaded in the application using the EncodedImage.getEncodedImageResource. The crash happened when the application tried to load the icon marked as rollover for the alternate entry point in the application descriptor. The workaround is have it set in code by the background thread (the one that starts on startup) instead of in the application descriptor:
net.rim.blackberry.api.homescreen.HomeScreen.setRolloverIcon(icon_rollover, 1);
An issue was created in the developer issue tracker, TOOL-138.
Stack trace of the error:
Exit SilverDust(230)
Error
No detail message
net_rim_cldc-26(4AE23629)
Resource
getIconOffset
0x533B
net_rim_cldc-26(4AE23629)
Resource
getIconBytes
0x53AB
net_rim_cldc-26(4AE23629)
Resource
findResource
0x5223
net_rim_cldc-26(4AE23629)
Resource
getResource
0x5164
net_rim_cldc-9(4AE23629)
EncodedImage
getEncodedImageResource
0x83DE
net_rim_cldc-9(4AE23629)
EncodedImage
getEncodedImageResource
0x83B0
Follow