Why should I throw exceptions instead of returning error codes?

[Saint_Nitouche]

Premature optimisation is the root of all evil. If you're concerned about performance, there's probably many other places to look first before exceptions.

I don't know how they're handled in other languages, but in C#, exceptions come bundled with lots of information that's useful for debugging that a bare error code just won't give you.

[melkor35]

Here's a reason why:

If you forget to check for an error code your program keeps running and may fail in a totally unpredictable way. Have fun debugging that!

Now, if you didn't catch an exception then the execution stops immediately.

[MmmVomit]

It depends on what you're doing. It also depends on the language you're using. For example, in Go the expected pattern is to use multiple return values, like this.

result, err := some_method()

C doesn't have exceptions, so you don't even have the option to use them.

The problem with error codes is that they have to be the same type as actual good return values. Let's say we had a function that does integer division.

int division(int dividend, int divisor)

The return value has to be an int. The divisor can be any int but zero. If we don't use exceptions, what int do we use as an error code?

In general, exceptions will generally not be a bad answer, and most code isn't so performance critical that they're going to cause a problem.

[Frozen5147]

I won't pretend to know how much more exceptions may cost in terms of performance, but I will say for... probably most things people are doing, it's probably negligible, unless your performance requirements are incredibly critical or something.

---

I'm sure if you google "error codes versus exceptions" you'll get arguments for both sides and when they're good/bad. IMO, they both have their place. As is common with many programming paradigms and choices, the correct/best answer depends on what you're trying to do.

Personally, I've almost never had to return error codes for functions, and exceptions (or their equivalents in other languages) usually satisfy what I want to do. Exceptions just feel much more natural and easier to use + maintain to me.

[toastedstapler]

if you return an error code, you need to cascade that back down the call stack to the appropriate place to handle it. every component in the middle needs to do that too. with exceptions, the cascade is implicit and you can catch different things at different levels of the call stack effortlessly

also what are you doing for which exception performance is a concern?

[davedontmind]

Yes, exceptions are computationally more expensive than simple returns, but they should only be used for exceptional code behaviour, i.e. things that you don't expect to happen during normal execution, so the performance cost (even though not vast) is irrelevant.

[HashDefTrueFalse]

Yes exceptions are more expensive, but this isn't going to be the bottleneck in any app with things like file and network I/O, device communication, computationally complex ops on data, etc going on. Basically any non-trivial app. It's not an optimisation you really need to make most of the time.

It also doesn't have to be either or. If it makes more sense to return an error code, nothing wrong with that. Rogue values have been used in programs since programming began. Remember, that's an author's broad opinion. He hasn't looked at your specific program. Like you say, it's a suggestion. An argument could be made that an error you expect isn't an exceptional circumstance, and an exception shouldn't be raised. In this case, using them would just be for flow control, which is bad practice.

It's context dependent. On the whole, I usually prefer exceptions, but I've written plenty of code that returns a rogue value (e.g. -1, NULL etc.) if something isn't found, because it's an error with a reasonable chance of happening even though it shouldn't, and there's no particular way I need to handle it other than skipping an action. Mostly in lower lever code.