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 Continue reading Blackberry Swallowed My Error
My knowledge of reverse polish notation came in handy today. It’s weird how these things come up in real life and not just in an academic setting. Granted, not every college graduate deals with the Excel file format.
Excel’s formulas are stored in binary spreadsheet files in reverse polish notation, which makes sense. There aren’t usually numbers in the file which say how many arguments a function contains, so we have to know that in advance to be able to understand the formula. You evaluate the arguments of a formula before the formula itself, so the stack at the point of evaluating the formula itself should contain exactly the number of arguments the formula has. It’s elegant when it works, but it makes it difficult to figure out when you have an error (unlike in XML where everything has boundaries)
Usually, if you read in more arguments than are available, an exception is thrown, and if you read in too few, an exception is thrown when evaluation completes and you have extra tokens to read. You could theoretically read too few arguments at one point and too many at another and just have an invalid result, but that would require two errors happening simultaneously, which is (hopefully) improbable.
I wish Resharper had a feature which pointed out where exceptions are being created but aren’t being thrown (ie, new Exception() instead of throw new Exception()). I also wanted a feature which automatically sets breakpoints where exceptions are thrown, although after thinking about that for a bit I’m not sure about that. I do really like the syntax checking for the most part, even if it messes up sometimes. And I still do go back to Emacs for anything repetitive; I haven’t seen anything in Resharper or VS that allows for Emacs-like macros.