• 0

Exception Handling


Question

We were having a discussion about the correct way to be handling exceptions. Naturally, I had to build an image to describe my thoughts:

post-92970-1249901792.jpg

Your thoughts?

Link to comment
Share on other sites

13 answers to this question

Recommended Posts

  • 0

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

  • 0

^ 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

  • 0
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

  • 0
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

  • 0
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

  • 0

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

  • 0
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

  • 0
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

  • 0

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

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.