3

There are two ways of error handling:

1) Use nested If and check errors

2) Use try/catch

Here is tutorial about this. But it is said here that try/catch hurts the performance. So, it seems there is a trade-off. How to decide? What should be done?

DaveFar
  • 7,078
  • 4
  • 50
  • 90
ndemir
  • 1,881
  • 3
  • 19
  • 25

4 Answers4

5

Exceptions hurt performance if you use them badly. Don't use them for things which are bound to come up all the time, and they're fine.

Basically, you should use exceptions when something is wrong - and typically when something's wrong, performance isn't terribly important. On the other hand, if you have to put all your error checking in manually, the chances of something going wrong are somewhat higher, IMO...

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • This is a web service function. I will use something like this: http://pastebin.com/wTVuTcDs. – ndemir Sep 15 '11 at 22:19
  • "Exceptions are for the exceptional" – Bohemian Sep 15 '11 at 22:23
  • I think this will be a better example: http://pastebin.com/E0DQmSj8 Because i will use custom exceptions. – ndemir Sep 15 '11 at 22:24
  • 1
    @ndemir: Do you really need *exactly* that level of granularity? Your web service code is going to get *really* tedious to write and use. Why do you think the callers care about all those differences? Is it really appropriate for the abstraction level they're working on? – Jon Skeet Sep 15 '11 at 22:25
  • @Jon Skeet, can you take a look http://pastebin.com/E0DQmSj8. What should I do not to use try/catch badly in this code? – ndemir Sep 15 '11 at 22:27
  • @Jon Skeet, this source code (http://pastebin.com/E0DQmSj8) is just an example. I should return error when user has not permission or not authenticated. I will use much more custom exception classes. – ndemir Sep 15 '11 at 22:30
  • @ndemir: Right - so at the end of this, I'm not really sure what your question is. At the web service boundary it's a completely different kettle of fish, in that it can't really throw an exception as such - it can only give a different response. – Jon Skeet Sep 15 '11 at 22:38
0

+1 for Mr. Skeet's answer. I'd like to add that your question implies an either/or situation, which it's not.

Try/Catch is only a performance concern if it's your sole method of handling errors. You need to ALSO use if/else to handle common, known cases. Save exception handling for exceptional cases.

For example, you can't predict out of memory errors, dropped network connections, or file corruption. In those cases you'd use try/catch.

groundh0g
  • 408
  • 3
  • 9
0

When creating/running an application you will always have some technical (network, io, os) and functional errors (i.e. programming/user).

Normally the handling of these errors should have been covered by the requirements (in real live not in academic space). When in doubt you should ask the client or functional architect.

You can be academic about this, but just follow the requirements and throw or swallow ;-).

lauwie
  • 301
  • 1
  • 5
-1

I'd say (premature) optimization is the root of all evil. So for exceptional behavior, I'd always go with try/catch!

DaveFar
  • 7,078
  • 4
  • 50
  • 90
  • That half-quote expands out much nicer, but the "rest" is generally left in the paper :( –  Sep 15 '11 at 22:11
  • What do you mean? Knuth's "Structured Programming with Goto Statements" paper? – DaveFar Sep 15 '11 at 22:14
  • Yes, it's part of a good bit longer section which is very complementary but often omitted :( –  Sep 15 '11 at 22:24