0

I often see catch clauses for Throwable in Blackberry documentation, such as the Network API docs. My sense is that this is not generally a good practice in Java.

Is there a reason for this in Blackberry programming?

Does it have to do with stack trace generation for Throwables?

Michael Donohue
  • 11,776
  • 5
  • 31
  • 44
Matthew
  • 44,826
  • 10
  • 98
  • 87

4 Answers4

2

When you catch Throwable in a BlackBerry app, not only does it preserve the stack trace, it saves that stack trace in the device event log. There is no way for an app to get a stack trace itself, so unfortunately you can't automatically collect stack traces.

To view the stack trace, you pull up the event log viewer. For blackberries with physical keyboards, hold 'Alt' and then press L G L G to bring up the event log.

Community
  • 1
  • 1
Michael Donohue
  • 11,776
  • 5
  • 31
  • 44
1

Read the documentation for java.lang.Error, which is a subclass of Throwable, and you'll see the problem with catching Throwable.

It says:

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.

For example, you could end up inadvertently catching a VirtualMachineError indicating the whole VM is in a broken state. Putting something in the finally block to run on broken VM doesn't seem like a good idea.

Michael Donohue
  • 11,776
  • 5
  • 31
  • 44
Mark Bolusmjak
  • 23,606
  • 10
  • 74
  • 129
  • I wonder why they suggest doing it then? I guess they're misguided. – Matthew Mar 11 '11 at 01:16
  • 1
    I believe that comment means you should not try to put in special handling for Error or subtypes NoClassDefFoundError, VirtualMachineError, FactoryConfigurationError, CryptoSelfTestError. This does not preclude logging or other general purpose handling to notify that something has gone wrong in your app. – Michael Donohue Mar 11 '11 at 01:42
0

I don't think there's a special reason. See the comment:

} catch (Throwable t) { // can also catch specific exceptions to include special hadling for the different types

It means the example is basic. And has a typo, and a bad practice. So catch specific exceptions if possible.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
  • 1
    I think there is more to this story as Throwable seems to be used everywhere. – Matthew Mar 10 '11 at 23:57
  • Catching Throwable is a bad idea for production app (see my reply to orig q), but for tests, prototypes, and other non-customer-facing stuff it may be appropriate. – seand Mar 11 '11 at 00:02
0

On the BB platform, if Throwable is caught it preserves the stacktrace and usually renders it on the screen, blasting in the user's face. Not very good for UX :(

When Exception (and extended classes) are caught the stacktrace is thrown away for efficiency reasons.

seand
  • 5,168
  • 1
  • 24
  • 37
  • 3
    I am a BlackBerry developer for OS 4.5 through 6.0, and I can tell you it does not render the stack trace on screen. Not sure where you got that idea. – Michael Donohue Mar 11 '11 at 01:37
  • It may not happen all the time but I've seen it occur enough that I avoid catching Throwable. BB OS have been known to cause UI effects that you seemingly didn't ask for. Ex. I've seen BES-related SSL errors in MDS connection actually cause device side popups. p.s. I've been working on BB since 4.1 – seand Mar 11 '11 at 03:04