I’ll start this post with a statement or answer that might seem controversial.<\/p>\n
The answer is ‘NO’<\/strong><\/p>\n Why? Let me explain. If your code has reached a state where an Exception has been thrown it means you have already missed something (possible) important that should have been addressed. Sure, throwing (excuse the pun) a ‘try… catch’ around every block of code is nice and all – and you should do it anyway (for other reasons) but it is no excuse for writing bad code.<\/p>\n More details<\/strong><\/p>\n One reason I say these things I recently (re)discovered myself… again is that ‘Performance’ in an application can greatly be influenced by exceptions since the whole process of encountering\/throwing an exception in code is a slow thing. When you have code that relies on catching an exception in order to handle an (possibly) expected condition of some variables it is a sign that you are doing it wrong… It may not be a big issue if the affected code is called only once in a blue moon but once it is in a section that is called repeatedly and is expected to perform at speed it becomes a huge issue.<\/p>\n Have a look at this code. It will run fine but and actually be usable but…<\/p>\n Now look at a better way<\/p>\n This code will actually run faster and does not rely on an Exception to handle something that should be done right to start with.<\/p>\n Ok, there you have it…<\/p>\n","protected":false},"excerpt":{"rendered":" I’ll start this post with a statement or answer that might seem controversial. The answer is ‘NO’ Why? Let me explain. If your code has reached a state where an Exception has been thrown it means you have already missed …<\/p>\n\r\ntry\r\n{\r\n SomeType tp = SomeObject.SomeVar;\r\n}\r\ncatch \/\/ null reference exception or something expected the first time\r\n{\r\n SomeObject = new SomeObjectType();\r\n ...\r\n}\r\n<\/pre>\n\r\nif (SomeObject == null)\r\n\r\nSomeObject = new SomeObjectType();\r\n\r\nSomeType tp = SomeObject.SomeVar;\r\n\r\n...\r\n<\/pre>\n