you just added some fields to your Screen and now the Screen won’t be pushed anymore.
does this sound familiar to yoo ?
as you know there’s no Console output while running a BB App without debugger attached, so it’s not easy to know what happens. Attaching the Debugger may take some time in complex environments so I always try to avoid those wasted time. That’s the reason why I’m using an own LoggingFramework – but thats another story.
Even Logging or Debugger doesn’t help immediately if you don’t catch Exceptions and print them.
So we want to take a deeper look how you can help yourself to make your App more robust from the beginning and not only per accident. In many cases perhaps you made a mistake while copy/paste some code. This is why I always hate copy/paste-development and like to generate code a model-driven way. but thats also another story. (you see there will follow many blog entries around BlackBerry development next months😉
… perhaps it happens while adding some Fields to a Manager, so lets take this as an example:
Taking a look at the JavaDoc it seems easy and you surround you code with a try/catch and you catch the IllegalStateException and the IllegalArgumentException.
You restart your App, but same as before: the Screen wasn’t pushed.
hmmm – perhaps another Exception happens ? You also catch Exception and print e.getMessage() and restart your App:
now something happens: an Exception was caught and a Message was printed ! … but the Message was ‘null‘ – so not really helpful😉
You add printStackTrace and attach the Debugger – but no StackTrace was printed. (see below)
But you can get more out of this situation:
at first its a good rule to catch Throwable instead of Exception if developing BB Apps. (more infos at the end of this entry)
as next add the Class of the caught Throwable to get more informations and always add the message – but maybe the message is null.
BTW: my logger.error method also does a printStackTrace.
here’s the output from my LoggingMonitor (Lilith):
Now we know, its a NullPointerException. Because your Screen now was displayed, take a look at the last added Field and you know which Field is null. You’ll see that you forgot to create this Field. You can now explicitely react on different situations: IllegalStateException if you tried to add a Field a 2nd time to Manager, IllegalArgumentException if you try to add the Field to itself and Throwable for all other cases. The good thing: the Screen will always be displayed.
Lets make a test what happens if you add a Field twice to the Manager:
Now we expect the IllegalStateException – and really this one was caught:
The IllegalStateException was caught and this time we also have a Message: “Field added to a Manager while it is already parented“.
Rules HowTo Catch: If you have to distinct between the different Exceptions, then catch all of them and as last Throwable – if you always react the same, then you only need to catch Throwable, but never forget to catch Throwable: it will save you much time.
Perhaps you’re wondering why printStackTrace didn’t work in the example above ? It’s the same reason why we have to use Throwable – here’s from the JavaDoc of Throwable – and no, its no april joke:
Please read it again: if you catch an Exception, the RIM VM removes the stacktrace ! Only if you catch Throwable, the StackTrace is available – you can get this StackTrace while debugging or from the EventLog of the Device, but its not as readable as you know from ‘normal’ Java. For me a good logging and adding all informations YOU have while catching an Exception can help. You can also follow this Thread at BB SupportForum.
We have to add to our rules: If you need the StackTrace, don’t catch Exceptions – only Throwable have StackTraces !
You want to take a look at a StackTrace from the Devices Event Log and don’t find it from the Menus ? There IS no menu – you have to hold down the ALT key and then type
as secret command. this will give you access to the Event Log.
Here’s what you’ll get from this Event Log in the first use case where we added an undefined Field (null) to the Manager: