Antaris Veteran Posted August 10, 2009 Veteran Share Posted August 10, 2009 We were having a discussion about the correct way to be handling exceptions. Naturally, I had to build an image to describe my thoughts: Your thoughts? Link to comment Share on other sites More sharing options...
0 Bazenga Posted August 10, 2009 Share Posted August 10, 2009 My thoughts exactly :p. Link to comment Share on other sites More sharing options...
0 hdood Posted August 10, 2009 Share Posted August 10, 2009 Exception-based programming is evil and unpredictable, and leads to more problems than it solves. Your thoughts? Link to comment Share on other sites More sharing options...
0 Guest Posted August 10, 2009 Share Posted August 10, 2009 I am a novice by any means but whats so bad about that... :o I often see an operation that may throw multiple exceptions types... I just catch them all under a system.exception rather than giving the same behaviour to all possible exceptions. Link to comment Share on other sites More sharing options...
0 Antaris Veteran Posted August 10, 2009 Author Veteran Share Posted August 10, 2009 ^ I can understand catching all Exceptions in certain scenarios (i.e. for a customer-facing website, which you don't want to fail back to a server error page etc. It's the throwing part which becomes something of a monster. Consider you have a method which which can fail. You know the expected reasons why it could fail, etc, but why would you fire a generic System.Exception instead of specialising the exceptions that could be thrown. public void ThisMethodWillFail(string parameter) { if (parameter == null) { throw new Exception("Parameter is null"); } if (parameter != "hello") { throw new Exception("Parameter does not equal \"hello\""); } } Any code calling that function would have to catch System.Exception (thats not a bad thing), but what then? How do they know what the exact cause of the exception was? public void ThisMethodWillFailSpecifically(string parameter) { if (parameter == null) { throw new ArgumentNullException("parameter"); } if (parameter != "hello") { throw new ArgumentException("Parameter does not equal \"hello\"."); } } In the above example, I could catch either an ArgumentNullException, or an ArgumentException, and possible handle those exceptions in a specialised way. The idea behind this thread is just an open discussion on (hopefully) a range of developers points of view. I hope to broaden these types of threads to include more things, like design patterns. Hopefully we can get some healthy developer discussions going :) Also, it may help centralise some development do's and don'ts that visitors to the forum can referrer to, but as an amalgamation of many developers pointers of view. If that makes sense? Link to comment Share on other sites More sharing options...
0 _kane81 Posted August 10, 2009 Share Posted August 10, 2009 Exception handling is defiently not evil - it has its place like all tools! Link to comment Share on other sites More sharing options...
0 Rob Veteran Posted August 10, 2009 Veteran Share Posted August 10, 2009 Exception handling is defiently not evil - it has its place like all tools! That's not the point of the original poster. Good thread Antaris! Will help remind me to be more specific when throwing exceptions, another one of those tips that help infinitely as your application grows. Link to comment Share on other sites More sharing options...
0 Antaris Veteran Posted August 10, 2009 Author Veteran Share Posted August 10, 2009 Exception-based programming is evil and unpredictable, and leads to more problems than it solves.Your thoughts? I disagree. Catching specific exceptions, is anything BUT unpredicatable. Care to add why you have this specific train of thought? Link to comment Share on other sites More sharing options...
0 code.kliu.org Posted August 11, 2009 Share Posted August 11, 2009 Exception-based programming is evil and unpredictable, and leads to more problems than it solves. Wow, it's rare to see someone who hasn't drank that kool-aid. /me agrees I disagree. Catching specific exceptions, is anything BUT unpredicatable. It's a lot less explicit what the exit points in your flow is when, through the wonders of exceptions, pretty much every statement can be a potential exit point. Link to comment Share on other sites More sharing options...
0 Bazenga Posted August 11, 2009 Share Posted August 11, 2009 I haven't really thought about Exception handling, however, according to my very shy experience, Exception handling allows me to have a centralize error catching mechanism. Link to comment Share on other sites More sharing options...
0 Antaris Veteran Posted August 11, 2009 Author Veteran Share Posted August 11, 2009 It's a lot less explicit what the exit points in your flow is when, through the wonders of exceptions, pretty much every statement can be a potential exit point. I can see where you are coming from, but isn't that where catching is beneficial. You can manage any potential errors in the flow of your application, and then design how to handle then, either as an exit point, or allow it to continue with some other value. Out of interest, what methodology would you use? Link to comment Share on other sites More sharing options...
0 Jexel Posted August 11, 2009 Share Posted August 11, 2009 It's a lot less explicit what the exit points in your flow is when, through the wonders of exceptions, pretty much every statement can be a potential exit point. it depends on the way you use it. You shouldn't be catching nullpointerexceptions in java since your code should be bound safe to begin with, on the otherhand if you are playing around with file io, it's perfectly logical to catch any fileio exceptions. The way I see it, never use exceptions to control flow. Link to comment Share on other sites More sharing options...
0 +Majesticmerc MVC Posted August 11, 2009 MVC Share Posted August 11, 2009 WARNING: Car Analogy follows... Catching System.Exception is like having a "fault" light on your car dashboard. It tells you that somethings gone wrong, but you'll never know what. ====================== Exceptions have their place, especially in areas where the code be broken by external factors. Device I/O for example can be coded perfectly, but if the device fails to do something, or does something that it shouldn't, then you need the exception handling to deal with the issue. File I/O too should have exception handling where necessary. If you are reading a file, and your code falls over, then you need a "finally" block to ensure that you still close the file connection. If you don't, then you're at risk of leaving the file locked until the process exits. However, it is a cardinal sin to attempt to use exception to control flow (like PCBEEF said). I've seen code that uses exceptions where an if...else statement could have sufficed, and exception handling to validate user input, where validation methods should have been written. Exception handling is designed to handle errors, not laziness. This technique is something that I've seen many people fall into, and once you do it, its not an easy habit to break (speaking from experience :p). If someone ever asks me about exception handling, I always point them towards this article on CodeProject which discusses best practices with exception handling. This is where I look and I don't think I've ever found any article that discusses it better. :) Link to comment Share on other sites More sharing options...
0 gertin Posted August 12, 2009 Share Posted August 12, 2009 Exception handling can get a bit out of hand though. In most cases the only thing you can do is notify the user or log that something went wrong. Link to comment Share on other sites More sharing options...
Question
Antaris Veteran
We were having a discussion about the correct way to be handling exceptions. Naturally, I had to build an image to describe my thoughts:
Your thoughts?
Link to comment
Share on other sites
13 answers to this question
Recommended Posts