Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
02-04-2010 12:26 PM
C++ has exception handling built in. I can see your point about handling exceptions but I am developing a video game. For video games it's common practice to have asserts through out the code and then they compile out in the final release. For performance reasons you can't afford the final build to have the extra overhead.
02-04-2010 12:31 PM
For video games and other real-time type environments I could see the value in using asserts, but I wouldn't use that as a substitute for catching and handling any exceptions that can come your way.
02-04-2010 04:09 PM
There is nothing wrong with it. That part of it is fine. It's the code above that that isn't so hot. If I am calling a function, I don't want to have to surround it with these little try/catch code blocks just to determine whether is succeeded or not. It really bloats the code and make it harder to read IMHO. I guess I don't consider the fact that say a file didn't manage to open as an exceptional condition Just return me an object and I will check if it's null and we can all move on...
02-04-2010 04:47 PM
You don't catch the exception, you intend to throw it all the way up the stack so your application dies when the assert fails (isn't that what asserts are designed to do?)
This, sadly, requires you to declare every method as "throws Exception", which is irritating.
02-04-2010 05:12 PM
Sorry. I misunderstood. I thought you were referring to the comment I made about how Java tends to use exceptions for flow control.
To use what you're suggesting, wouldn't you still have to make sure that you catch this exception at various points? What do you do if you're in a callback from the OS and you don't own the code above? Wouldn't you have to put try/catch blocks in all your entry points that the OS calls? Or are you suggesting that if I just let the exception happen, that the OS will show a message? I thought I tried this but perhaps I am mistaken.
02-04-2010 05:18 PM
There are some tricky situations involved with this, you're right, I think.
But what you want is the application to get killed hard if an assert fails, and receiving an uncaught exception will do that. I think the OS might produce a dialog in this instance with the error message, but one would need to test this; regardless, you're interested in seeing debug or log output when this happens, and this is what it should produce.
02-04-2010 07:42 PM - edited 02-04-2010 07:43 PM
Ideally you will wrap everything at the top level with a try-catch and then do a system exit. Assert won't help you when it's a runtime image.
Incidentally, it's amazing how many "commercial" BB apps that I've got NullPointerExceptions or IOExceptions on through normal usage.
03-03-2013 08:36 AM
It's best not to confuse the purpose of assertions and exception handling; the distinction is between programming errors which should not happen and which assert is made to find and runtime errors where a condition occurs which the program has no control over, e.g. a file is missing, a network packet is corrupt, etc. For example, if you have an algorithm that has a loop, you can assert that progress is made on each iteration. If you have another example where it is not possible to delete a file then an exception should be thrown. In this way your program's error handling is split conceptually into program defects which you expect never to occur and runtime errors which may or may not occur.
Assertions are also used to document contracts between methods, check post conditions and object invariants.