2

I've looked at a few other questions (especially Parsing Performance (If, TryParse, Try-Catch)), and am thinking about the answers. Is it an abuse of exception handling if the exception shouldn't be thrown? Isn't that the whole point of it? Catching the error in the rare case that something goes wrong?

To be exact, I'm getting some xml data from a service and am wondering if I can assume that it is correct (with the .00000001% that a bit / something else got lost in the internet).

Edit I'll probably use Linq to XML, but the question still stands.

Community
  • 1
  • 1
SBoss
  • 8,845
  • 7
  • 28
  • 44
  • The "problem" with exception handling is that it always creates some overhead, even when no exception is thrown. I would go with the accepted answer of the question you reference to. – Marcel Nov 30 '11 at 08:35
  • @Marcel the overhead when it doesn't throw is very minimal, but exceptions aren't a good way to do flow control, for sure – Marc Gravell Nov 30 '11 at 08:56

2 Answers2

2

I look more at the scenario than the performance; if the expected behaviour is that it is valid, I generally use Parse (or ParseExact if available), and let the exception go. Unless I need to raise a specific error, in which case TryParse is handy.

If the data might be (say) an integer, then TryParse is preferable over Parse+catch.

With LINQ-to-XML: don't parse; instead, use the static conversion operators provided; so rather than:

...
select int.Parse(node.Value);

you should use

...
select(int) node;

this is even more important for things like DateTime, as it takes into account the standard XML formats. It also does the "expected" thing if the node doesn't exist (i.e. node is null):

select (int?)node;

will return a null value rather than throwing a NullReferenceException (which node.Value would do). There are static conversion operators for most expected data-types.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • did you mean cast, instead of "case"? – Marcel Nov 30 '11 at 10:18
  • `DateTime` is an interesting choice for an example for using the cast. It's one of those places where I'd do the parsing and conversion myself to make sure nothing strange happens. – CodesInChaos Nov 30 '11 at 11:35
  • @CodeInChaos it depends on what format is expected, I guess; if it is the standard xml date/dateTime/etc then the conversion operator will do the job cleanly – Marc Gravell Nov 30 '11 at 11:45
0

I assume the service usually returns valid data, but I'd still try to guard against failure in an external component. If the service is under your own control and you are very sure it will never return invalid data, you can simply use Parse and be done. But if it's not under your control, handling failures gracefully is nice.

I'd put a catch clause at the outermost level of the code that handles the parsing. And translate any parse error into a generic "invalid data from service" exception with the original exception as inner exception.

Then the calling code can handle that one exception, so it doesn't shut down your whole application.

CodesInChaos
  • 106,488
  • 23
  • 218
  • 262