Hi All,

What do you think of the following statement: "Every method you create should have a try-cacth block?"

I personally disagree with that statement coz firstly not all methods throw exceptions so I only include it when there's a possibility of an error + I also think it can slow down a program substantially.

Many Thanks
Eric

 

You include data entry checks at every point in a Program that human input is needed. Some functions, as you say, self check, however, you still need to protect the program from garbage inputs, because fools are very ingenious when it comes to finding ways to screw things up you thought worked well.

Idiot proofing is the phrase I learned it by

 

Hi All,

What do you think of the following statement: "Every method you create should have a try-cacth block?"

I personally disagree with that statement coz firstly not all methods throw exceptions so I only include it when there's a possibility of an error + I also think it can slow down a program substantially.

Many Thanks
Eric

That approach strikes me as what I call "monkey talk" -- basically trained monkeys that only know how to follow simple rules and lack the knowledge to actually think for themselves.

Having said that, there are probably non-monkeys out there that subscribe to that general philosophy but who backstop it with a lot of "except when ..." and "unless ..." clauses.

My personal approach is to only use try-catch blocks when there is something I can reasonably do about an exception when it is thrown. If I can only die, then can I die gracefully in a meaningful way? If not, then what's the point? Now, if I was writing production code for consumers (which I don't) I might well take a different approach and say that making an otherwise unhandled exception appear to be a somewhat orderly program exit has value.

As for the performance hit, I think that lots of try-catch blocks probably do have a significant impact on performance, but the real question is whether the slower performance is still good enough. If it is, then this is not a good reason to forego proper exception handling (leaving aside the question of exactly what constitutes "proper"). In many (most?) situations where performance improvements are really that important, then there is a good chance that the program should be written in a language that doesn't support sophisticated exception handling (and lots of other things) to begin with, but those applications are few and far between when all is said and done -- but they definitely DO exist.

 

If you are writing a high-level application, it's almost always better for the application to intelligently die with a specific message to the user as to why it died. This helps your customers participate in debugging your code. Nothing bothers me more than when an Android app quits with the generic message "The application has stopped."

With that said, my low-level code never includes a "try-catch" structure -- it simply isn't supported by .asm. But, I still endeavor to account for all possible values of data input and all potential results of calculations and branches.

Be careful: "try-catch" is one of those constructs that makes programmers lazy. Why should one check bounds when the run-time engine will do it for you? It's the "When all you got is a hammer, all problems look like a nail" approach.

As an alternative, the assert construct is highly valuable for debugging purposes and, AFAIK, has no impact on the final (release) run-time performance.

 

Also, if you are going to "try-catch" all your function calls, be sure of 100% coverage of all possible exceptions. This requires investigation of each of the library calls -- and each different exception may require a different handler.

 

Maybe that needs to be reworded to say exceptions should always be handled properly. There are multiple ways to handle exceptions, try/catch is one way, but not the only way. Different exception handling methods are better fits for different projects, use what works best for that specific project. But always do your best to catch all exceptions and provide some sort of useful feedback, whether it be to the user directly or to whatever logging method is in use.

 

Funny example:

I've got an Android app called "Flight Pilot" which is a rudimentary flight simulator (easy enough for kids to fly). One of the planes available, the Spitfire, has a bug where you can fly it in excess of 1000 knots. In that "mode", if you bank just right, you can fly it at near light speed until it explodes. Some bounds checking would have been nice -- but less fun.

 

Thanks all for your interesting comments! All I can say is that it hurts/upsets me when I am told to add try-catch to all methods when I know that some will NEVER throw an exception and you can't really argue with your superior...

 

Thanks all for your interesting comments! All I can say is that it hurts/upsets me when I am told to add try-catch to all methods when I know that some will NEVER throw an exception and you can't really argue with your superior...

If your employer requires exception handling, then that is the job description. Why argue? Just do it and get paid.

 

... Just do it and get paid.

Hahah I like that but I think you get what I mean... I added to make them happy but if it was a personal project/application I would not put it everywhere unnecessarily! I only put it when there's a possibility of an error. Anyway...

Thanks all again for your interesting comments! Btw, it's been a while since I touched asm I kinda miss it.

 

If your job requires exception handling to be done via try/catch, then that's what you have to do. Insisting that every method employ try and catch seems like a bit of a blanket statement, so maybe they just meant handle every possible error condition and handle it via try/catch.

Exception handling really can be a very significant part of your design, sometimes it's even the most significant part. The code path where everything goes right is often the easy part, it's all those infinitely different cases where something goes wrong that can take the real thought.