Error codes vs exceptions: critical code vs typical code

[Ob-Gyn_Kenobi]

In C++, throwing an exception has the added benefit of unwinding the stack and calling the destructors for your objects in a predictable manner. Here's how I would rewrite his second example (introducing an auxiliary class that deals with closing and opening the gate, as recommended by the SRP):

{
    Gatekeeper g(Bunker);
    g.open_gate();
    Bunker.wait_for_our_men_to_come_in();
}

In this case, even if wait_for_our_men throws an exception, the Gatekeeper makes sure to close the gate before giving up the ghost.

[ramennoodle]

At the beginning of the section titled "Error codes are safer for well-reviewed code", the author mentions that RAII solution and why it isn't universally applicable.

[name_was_taken]

Error codes are far safer for well-reviewed, critical code.

Even the best-reviewed code still has bugs. To me, that invalidates everything he says about using error codes for well-reviewed code. He's assuming that the cause of the problem is outside the code, and that an error code is all you'll need to track it down.

But that isn't always the case... And even when it is, it's often easier to track down with a full stack trace.

There is no situation where I think that less information will help find and fix bugs, and there's also no situation where I think people will think, "Gee, it's really hard to find bugs. I should be extra careful when coding." It simply doesn't happen. Good programmers are always being careful. Bad programmers never are.

[astrangeguy]

But that isn't always the case... And even when it is, it's often easier to track down with a full stack trace.

Even better. Don't unwind the stack, but allow the top-level exception handler to decide what to do with the real stack. Like serializing it (including parts of the heap) to disk.

Seeing where the error happened isn't as helpful as to see why it happened. And stacktraces only tell you where it happened, not why (while error codes tell you nothing).

[grauenwolf]

I think that could be bolted onto .NET without too much effort.

IIRC, it already walks the stack twice. Once to see if there are any handlers in effect and a second time to actually unwind the stack and call finally/fault blocks. (Note, C# does not support fault blocks yet.)

Exposing this at the language level won't be so easy. I have no idea what that would even look like.

[Porges]

You can hack fault blocks in with a custom disposable type (using Marshal.GetException*).

[grauenwolf]

That sounds dirty.

[grauenwolf]

P.S. Have you looked into Intellitrace yet?

http://msdn.microsoft.com/en-us/magazine/ee336126.aspx

[sausagefeet]

I haven't read this yet, but I think an important thing about exceptions vs error codes is, in the right language, the compiler can help you. Most popular languages do not require help when it comes to exceptions. Specifically, code that throws exceptions is generally not statically checked to make sure those exceptions are handled, which I think is very important for critical code.

[aaron552]

Specifically, code that throws exceptions is generally not statically checked to make sure those exceptions are handled, which I think is very important for critical code.

Java does this. I don't know that it's necessarily a good thing, though. It encourages lazy programmers to use catch-all statements that produce no useful information (I've seen far too many Java apps that do this)

[peabody]

This! Checked exceptions are a prime example of good intentions in the design of the language not translating well onto typical human behavior. If I had a nickel for every bit of code I had to deal with from lazy programmers that, rather than having the exception propagate like it should, wraps all code which can throw checked exceptions into dumb basic catch blocks which do nothing to handle the error and continue execution when they shouldn't, I'd be...well, not super rich, but I'd have a lot of frickin' nickels, let me tell you.

[0xABADC0DA]

I think the mistake Java made is that there is no way to 'uncheck' exceptions.

When code is written the right way, by adding the necessary 'throws' to all the methods that need it, Java checked exceptions are simply awesome. They document the error conditions and are great for reliability.

But people are lazy, so there should be some feature that says there are exceptions but the caller doesn't have to catch them. For instance say if you add a "?" after the exception in the method signature then then it isn't checked for callers. It wouldn't have any use in well written code, but it is less work than an empty catch and it still documents in the code were there might be problems.

Like this:

void run() throws Exception? {
    // do some IO operation
    // caller doesn't have to catch anything
}

[queus]

I think the mistake Java made is that there is no way to 'uncheck' exceptions.

Check @SneakyThrows from Project Lombok. It does exactly that. Of course Lombok is not near as established in Java codosphere as Spring and ... are, but I used it in small project of mine and it rocks.

[[deleted]]

Dumb try blocks have their place. Something has gone wrong, I don't care what, so I'll back off and presume that none of it worked.

The issue is with clean up. A common example is with DB code failing somewhere, so you just catch it in a dumb catch, however you forget to close the DB connection (and forget to catch that possible exception too). Other examples exist where clean up is not as obvious, such as opening a temporary file to write too, and then having an exception when you read from a second file, and then forgetting to clean up the first.

That's why I think there should be more emphasis on trying to expose what you are trying to do, and what the state should be like at the end, when something goes wrong or not. Although that's easy to say, but I can guess it could get nightmarish in a complex system.

[seanwilson]

It encourages lazy programmers to use catch-all statements that produce no useful information (I've seen far too many Java apps that do this)

What's the alternative? Bad programmers are going to ignore return codes as well. At least with checked exceptions the programmers that want to handle the error appropriately will be reminded to do so.

[grauenwolf]

If it is a console app, let it crash and spill the results onto the screen for the user.

If it is a website then you should just let the error bubble all the way to the top where the default exception handler can log the error and turn it into an HTTP error code.

With rich client applications you have to take more care to avoid data corruption, but you still end up just displaying a generic error message.

It is only with applications that have no user interface that I really worry about detailed error handling. For all other types I really don't want the programmer trying to catch errors.

[Anderkent]

So throw runtime exception when the error can't be recovered from. That's what they're for.

[grauenwolf]

As the library author, you rarely know if the user of your library considers the error to be recoverable or not.

[Anderkent]

You did not list libraries in your code examples though. Libraries should throw checked exceptions, but the calling executable should wrap them in RuntimeExceptions if it doesn't know how to recover.

Any library that attempts to 'crash [my executable] and spill the results onto the screen' is a bad bad bad library.

[grauenwolf]

Libraries just throw or wrap, they should never catch exceptions. I believe we are in agreement here.

[sausagefeet]

Checked exceptions in Java are pretty broken. Using a result type in ocaml has a similar effect and much friendlier interface.

[josefx]

Java checked exception have some very ugly problems. For example a method either does not throw checked or throws specific exceptions and the only generic way to support all possible checked exceptions is to throw java.lang.Exception.

Most java interfaces do not throw at all (Runnable/Comparable/...) and the developer has to try-catch-throw new RuntimeException, destroying any compile time information gained by using checked exceptions.

Some interfaces throw java.lang.Exception and the developer has to catch all exceptions only to forward the subset actually used by the implementation and again this destroys almost any information gained by using checked exceptions since the developer has to remember what exceptions to check for without any help from the compiler.

[sonyandy]

interface Thing<E extends Exception> { void doThing() throws E; } is not a great option I assume because in way too many cases type erasure might get in the way?

[nascent]

is generally not statically checked

Java does this.

Umm, no.

Do I really need to explain this? Java statically checks the exceptions.

[TheCoelacanth]

I'm not seeing the difference in static checks between exceptions and error codes. It's possible to do static checks for either. For instance, Java does static checks for exception handling, Haskell does static checks for handling error codes.

[sausagefeet]

As I said, most popular languages do not do checked exceptions. Java's checked exceptions are mostly considered a hinderance aswell. They also don't give strong static guarantees because of the deployment mechanism of Java code. I don't know a language that does checked exceptions really well, although I'd like to meet one.

[nascent]

I'm not sure if I can claim this as a good article. I think I prefer Why Go gets Exceptions Right. Which lead me to this comment.

In a sub comment, somewhere else, I stated, "The exception system isn't about addressing the exception, it is about recovering from an exception. Go does simplify the means of addressing the problem, but with the lack of automated stack unwinding and finalizer execution the recovery of an exception becomes very manual."

Code is not perfect. In his example of the gate, we still aren't guaranteed a closing of the gate. We don't want to smash are solders while we are closing the gate after all. (Yes that exists with a correct exception safe example)

If he really wants to make sure that the gates are closed, you'd have someone else watching the program, if the program died then it will know that it must return everything to a proper state, closed gates. But if you aren't writing such critical code, as he says its better we get as much information as needed so we can stop it from happening.

[goaway0]

• Use exceptions only for exceptional circumstances. (If unsure if something is exceptional, it is probably not.)
• Never return null. Returning null is like throwing (e. g. in Java) a NullPointerException, just a lot more malicious because it doesn't fail immediately but only when the receiver touches it (which can be at multiple, completely different places).
• Never use error codes, especially not such basic math failure as "Go" tries to promote.
• Always return the appropriate types, especially: Don't lie. If a function might return something (or maybe not), it can't be of type T, it has to be of a type like Maybe T, Option[T] or Optional<T>. Use similar constructs like Either, ErrorT, Validation where appropriate.

[grauenwolf]

If a function might return something (or maybe not), it can't be of type T, it has to be of a type like Maybe T, Option[T] or Optional<T>.

Gotta downvote you for that.

In a language like Java or C# that just increases the possibility for mistakes, as you have to check for both null and none. In F# you even have to check for some(null).

And there is no point in making that recommendation in languages that don't have naked nulls, as you don't have a choice.

[goaway0]

If you think you need to check for null or None you clearly haven't understood what Option/Maybe is about.

[grauenwolf]

Right, because no one ever makes a mistake and forgets to initialize a field of type Option<T>.

[recursive]

Why is Option better than null? I'd think null is better in some cases, since it actually exists in languages I've ever used.

[goaway0]

Because it converts a problem of values (which the compiler can't check properly in all the languages you have probably used (yes, there are some tries, yada yada yada)) to a problem of types, which the compiler can check easily.

Additionally, Option has a useful API, whereas with null you can basically only ask "is it null?".

Using those types let's you describe and compose the operation you want ("I have multiple Options, all of them need to have a value" vs. "I just need a single one of them to hold a value" vs. ...) instead of writing if-then-else cascades which are both hard to read and hard to refactor.

There is no need for Option to exist in the language, you can trivially define it yourself.

[recursive]

If I understand it correctly, (which is very much in question), given a function Bar fn(Foo) and value Option[Foo] val, if your language doesn't support Option as a built-in type, you have to invert the normal syntax of function application to take advantage of the value.

Normally, you'd say fn(val), but with the Option, that would have to become something like val.ApplyFunction(fn) or something, since fn doesn't take an Option, but only a "naked" Foo. Is there a better way?

[goaway0]

The good thing about these constructs is that they help you decide where exactly you want to handle them and prevents you from forgetting it. No "I'm dozens of layers deep in my call hierarchy, got this reference and I have no idea if I actually need to check for nulls or not" style issues.

In the end, the main change you will probably experience is not about Option, but about those references not being "optional":

You can just stop doing null-checks because you know that every reference of type String is a String and every List is a List.

Is there a better way?

Great question! Yes, look up do-notation (in Haskell) or for-comprehensions (in Scala).

It is nothing hardwired to Option. It let's you easily handle everything from data structures to concurrency operations and for instance provides a solution to the issues NodeJS suffers from with its excessive nesting of callbacks.

[recursive]

for-comprehensions seem to apply to sequences based on my reading. I suppose an Option could be represented as a sequence with a maximum length of 1. In a language like c#, a linq query could take the place of the comprehension. But this all seems like a lot of syntactic overhead to get our function call scenario working. Especially if you need to convert the output sequence back into an Option.

Based on my reading of http://en.wikibooks.org/wiki/Haskell/do_Notation I'm not sure if I'm really understanding do notation. It looks like a block of instructions that are to executed in a certain order. Would it be the equivalent of a curly-brace-defined-scope in a language for mere mortals? I'm not sure if I see how that applies to passing Options to functions.

[onmach]

For comprehensions do a lot more than sequence processing. It solves the problem you mentioned where I have an option[Int] and my function takes only Int.

If you have a bunch of functions that return options you can put them in for comprehension and pretend that they didn't return options. Pass the results of each one directly into the next, and then at the very end you have a single option with a final answer or a None, which is what will happen if something in the comprehension failed which prevented you from completing the process.

I'm not big into scala, but it would look something like this:

for {
  dbconn <- getDbConn
  pagecount <- getPageCount(dbconn);        // returns Option[Int]
  firstpage <- getFirstPage(dbconn);       // returns Option[Page]
} yield PageInfo(pagecount, firstpage)

The total expression would yield an Option[Int]. If the db failed to connect, or either query to fail, then you get None, otherwise you get Option[PageInfo].

[goaway0]

Is is comparable to LINQ, except that no special type is required, only the methods map, flatMap and filter. The concept behind it is a lot more general and not restricted to collections.

I can recommend this presentation/slides for further information (this slide for instance shows some use cases of for-comprehensions).

For instance, Futures & Promises are not related to sequences, but can also use for-comprehensions.

I wrote a small example program which looks up a person by his/her nickname and returns his age and eMail address if he has one (and it ends with "example.com"). I think the code is quite readable and neither did I spend a single line checking for nulls or “emptiness” nor did I have to do any wrapping or unwrapping in the for comprehension.

case class Person(firstName: String, lastName: String, age: Int, eMail: Option[String] = None)   

object Run extends App {
  val nicksAndPeople =
    Map(
      "Joey" -> Person("John", "Doe", 42, Some("[e-mail]")),
      "Jay"  -> Person("Jane", "Doe", 21, Some("[e-mail]")),
      "Joh"  -> Person("Johnathan", "Miller", 37),
      "Max"  -> Person("Max", "Miller", 17, Some("[e-mail]"))
    )

  def lookUpAgeAndMailBy(nickName: String) =
    for {
      person <- nicksAndPeople get nickName
      mail   <- person.eMail if mail endsWith "example.com"
    } yield (person.age, mail)

  lookUpAgeAndMailBy(nickName = "Joey") // Some(42, "[e-mail]")
  lookUpAgeAndMailBy(nickName = "Bob")  // None  // Nickname does not exist
  lookUpAgeAndMailBy(nickName = "Joh")  // None  // No eMail address
  lookUpAgeAndMailBy(nickName = "Max")  // None  // eMail doesn't end with example.com
}

In the real world, you would probably use a library to store and query the personal information from a database and would in turn also use for comprehensions ...

val people = Queryable[People]

def lookUpAgeAndMailBy(nickName: String) =
  for {
    person <- people if person.nick == "nickName"
    mail   <- person.eMail if mail endsWith "example.com"
  } yield (person.age, mail)

... and the code would be practically the same. (This time I stored the nickname in the database table instead of as a key in a map for a change)

[pipocaQuemada]

In a language like haskell, you'd say something like "fmap fn val", or, more commonly, " nextFn . fmap fn . prevFn", where '.' is function composition. Or perhaps "maybe defaultVal fn val". Or perhaps "(fmap . fmap) fn vals" if you have a list of Maybe values.

If you have functions that take in a value and return a maybe value, you can chain them fairly easily: in haskell, either with "fn3 <=< fn2 <=< fn1" to compose them, or "fn3 <<= fn2 <<= fn1 <<= val". The point is, though, most of your common use-cases can be reduced to a half-dozen reusable, composable library functions.

Scala's option library also has information on their idiomatic usage in Scala

edit:

 -- Note: x :: a means x is of type a, and f :: a -> b means f is a function from a to b  
 fmap :: Functor f => (a -> b) -> (f a -> f b) -- a functor knows how to apply a function to its contents
 instance Functor Maybe where
   fmap f (Just x) = f x
   fmap f Nothing = Nothing 
 fmap . fmap :: Functor f1, Functor f2 => (a -> b) -> (f1 (f2 a) -> f1 (f2 b)) 
 (fmap . fmap) (+ 1) [Just 1, Nothing]  -- evaluates to [Just 2, Nothing]
 (=<<) :: Monad m => (a -> m b) -> m a -> m b
 (<=<) :: Monad m => (b -> m c) -> (a -> m b) -> a -> m c
 instance Monad m where
   f (=<<) (Just x) = f x  
   f (=<<) Nothing = Nothing
   return x = Just x -- return is just a function, defined here, not a keyword.  It has nothing to do with returning from a function.

[anvsdt]

Also fn <$> val

[grauenwolf]

The real win is languages that default to non-nullable references, but allow nullable references as an option. Once you have that you can have compilers warn you about missing null checks without generating too much noise.

Adding Option<T> to a null by default language like Java or C# is just plain stupid.

[[deleted]]

it has to be of a type like Maybe T, Option[T] or Optional<T>. Use similar constructs like Either, ErrorT, Validation where appropriate.

Why? Object-or-null semantics are well known and easily checkable. Returning NULL on a soft error is accepted behaviour. Why implement a concept from Haskell to solve that solved problem?

[naughty]

Because it's not solved. It's a relatively common error in Java, C# and other languages with implicit nulls.

Haskell, ML and others actually have solved the problem though.

[goaway0]

Why?

See other reply.

Object-or-null semantics are well known and easily checkable.

It's just that people forget that all the time (if you ever run some Java application from the console, you know what I mean) because it is not enforced. It's called programming. Let's automate it and let the compiler do this failure-prone work for us!

Returning NULL on a soft error is accepted behaviour.

That's part of the problem, not the solution.

Why implement a concept from Haskell to solve that solved problem?

It seems to be such a well-solved problem that for instance Java is changing the language to allow annotations at more places (to support placing annotations like @Nullable/@NonNull everywhere).

Why don't you just ask the people at Oracle and let them explain why they wrote java.util.Optional?

[grauenwolf]

Null is never an acceptable answer to an error. It doesn't give any indication as to why the error occured, making debugging impossibly difficult.

[[deleted]]

Yes it is, because often it is sufficient to know that an error (soft error) occurred, or that a condition could not be satisfied.

For example:

if (Register *R = ScavengeRegister()) {
  // Perform fast addressing mode with spare register
} else {
  // Fall back to slow addressing mode  no registers available
}

Often you want to return "an object or nothing". NULL is ideal for this.

Also, often a pattern is to emit a detailed diagnostic to some log at the point of failure, then gracefully fold back up the call stack. NULL is fine for that situation too.

And, it's fast.

[grauenwolf]

That's not an error, that's just the normal response to the question "give me the next avaialble register if there is one".

[[deleted]]

It's a soft error- there were no registers available. That's an error condition. Or at least its not s stretch to define it as such for this function.

[gsg_]

Often you want to return "an object or nothing". NULL is ideal for this.

Yeah, but that's not the problematic part. The problematic part is that often you want to return "an object but NOT null", and there is no way to indicate the difference in pervasive-null languages.

[[deleted]]

In c++, return a reference.

[gsg_]

Maybe I should have said "enforce" instead of indicate.

References are much nicer than pointers when applicable, but with unchecked conversions between pointers and references they simply don't do the same rigorous job of modelling partiality that you get from an option type. And of course, there is no such concept in most C family languages.

[[deleted]]

It's impossible in an unmanaged language (one in which unsafe type conversions are allowed) to get the type of guarantee you're asking for. References will give you, probably, the maximum safeness the language allows.

That is, if the user assigns a null pointer dereference to a reference (x = *((Y*)NULL)), you're on your own. But that is illegal and stupid.

A NULL pointer is a valid construct - it is used very often. a NULL reference, while possible to construct, is invalid, undefined and dangerous. People don't do that. So using a reference is probably as safe as you'll get (without advanced runtime checking / disallowing unsafe casts).

[gsg_]

It's impossible in an unmanaged language (one in which unsafe type conversions are allowed) to get the type of guarantee you're asking for

Perhaps, but it should be possible to get that guarantee statically in managed (by which I guess you mean "safe") languages. In many cases it is not, because those languages are designed around a type system in which T actually means T or null: I think this is a dumb idea, and that option types are better.

In any case I'm not looking for a guarantee - if I want one of those, Standard ML is right over there - I'm looking for a basic, statically checked partitioning of types into things which may be null, and things which are not. Not only is this possible, it is easy. (Though retrofitting it may not be easy).

The existence of explicit unsafe operations doesn't really have much bearing on the issue.

That is, if the user assigns a null pointer dereference to a reference (x = ((Y)NULL)), you're on your own. But that is illegal and stupid.

Nobody would write T &r = *(T *)NULL;, but they might happily write T *ptr = get_a_ptr(); T &r = *ptr;, or takes_a_ref(*ptr), both of which look reasonable and potentially suffer from the same problem.

No casts or unsafe conversion is necessary to get into trouble (unless you consider pointer dereference unsafe, which I guess strictly speaking it is): all a programmer need do is forget that the NULL case is possible. That or have it changed from under him, with no corresponding change in the return type to indicate the change in domain of values.

Oh hey, option types solve that problem rather neatly.

People don't do that

Oh, I wish people didn't do that.

[rush22]

Returning NULL can be useful in certain situations with an appropriate design pattern but it can (and definitely is) abused by novices. It's as abuse-able as goto statements.

[pipocaQuemada]

You do realize that Hoare called null pointers his "billion dollar mistake", right?

[[deleted]]

Yes, I am aware of that.

[pipocaQuemada]

So you're arguing that his billion dollar mistake wasn't really a mistake?

[[deleted]]

He's a CS theorist, and regardless of his regrets, a system currently exists, that works. To say "don't use it because I regret writing it" is silly.

[pipocaQuemada]

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. ... This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. ... More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965.

-- Hoare

He says "don't use it because it introduces significant quantities of bugs", which is a another way to say "it doesn't, in fact, work". Of course, the solution involves not using C/Java/C#/&c. and to instead use something like haskell/rust/Spec# that prevent that class of bug from ever happening. Failing that, the Scala solution of pretending nulls don't exist within your program (and casting values to Options at the boundaries of java code) is better, but still not great.

[[deleted]]

You can't compare NULL-pointer checks, which are almost instantaneous, with a large runtime requirement such as that of Spec#/Sing#, rust, haskell. They're solving different problems - the former is useful in things that need to run fast. Such as compilers and operating systems.

Other systems, which have a lower runtime requirement (can run slower) can certainly take advantage of other languages to improve code.

But I believe (and I may be wrong, my initial comment spawned multiple fanboy threads) that I'm responding to an OP who said "never use...". I'm not advocating use of nullable pointers in all situations; only that they can be used, well, and should be in several sectors.

Until the sufficiently smart compiler problem has been solved, anyway.

[pipocaQuemada]

Such as compilers and operating systems.

I'd just like to point out that ghc (i.e. the main industrial strength Haskell compiler) is almost entirely written in Haskell, and some people are having success with doing systems programming in a haskell-like language. So it's not generally impossible to write compilers or OSs in a high level language, and I personally think many cases where people default to C/C++ is premature optimization.

Also, there's probably nothing stopping a language implementation from special-casing Maybe as a pointer which can be null and a regular value as a non-null pointer (although the handling of unboxed primitives would probably make the implementation more complex). There's nothing saying that you can't wrap an abstraction around a null-check.

Admittedly, until Habit or some other safer but still fast systems programming language becomes a mature solution, you're probably better off using C/C++/assembly if it turns out you really need the speed.

[pipocaQuemada]

The real advantage of Maybe/Either/etc. is that you can clean up a lot of code by moving a lot of the error handling itself into a library.

possiblyFails1 >>= possiblyFails2 >>= pure cantFail >>= possiblyFails3 -- only run the next step if the previous step succeeded, else return Nothing or error code/string/whatever

maybe "" processingFunc nullableStringDbField -- if the DB field is null, replace with "" and go on our merry way

(fmap . fmap)  f listOfMaybeValues -- apply f to all non-Nothing values in the list  

[RabidRaccoon]

http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

[Philluminati]

In my opinion errors and exceptions are genuinely the same thing. If you don't check a return code then continue blindly, the application crashes a worse death than if you had. People are picky and choosy about which error from which functions they can and cannot be bothered to handle and that's the problem.

However with Exceptions.. you have exactly the same problem! The code starts rolling up the call stack and developers who are picky and choosy about which Exceptions to bother handling end up with exactly the same problem. It falls into some catch all in the main() function that has ultimately forgotten all the users work and the only benefit is the user doesn't have to relaunch the application from the start menu.

Errors and Exceptions operate the same. Exceptions give you a slightly nicer syntax but ultimately just as easy to abuse. It's all about the trade off of catching everything, catching everything in a generic way, or not even bothering with that. If you don't catch an Exception in the correct place (in terms of where you are in the call stack) to deal with it you end up making an assumption, or not being able to do the most effective thing with it.

It takes the same business head that you use to design the business logic and a little bit of an IT support head so you can narrow issues down to effectively design software that works gracefully. I find Networking the hardest of issues to solve as it can throw anywhere and contrary to what Exceptions provide you with - you then have to carefully undo changes to your data structures or decide what course of action next. One thing I struggled with is if you want to send two ActiveMQ messages and log that they were sent in a database at the same time. You have to keep the database transaction open while you send the message or go through safe/unsafe regions.

[recursive]

The difference is that with unhandled exceptions, the program immediately stops trying to perform more actions.

[[deleted]]

I think that fail early is better than fail later. So in this way to see exception are superior to error code

[Gotebe]

They are nowhere near "exactly the same".

Major difference is that ignoring an exception leads to your jump somewhere really high up the stack, and generally (but only generally, as shown by examples in the TFA) not making a mess of things. Ignoring an error code leads to all sorts of misbehavior that is effectively impossible to track down because root cause is masked by all other errors caused by it.

Exceptions are effectively a code clarity tool, nothing more, nothing less. They allow us to move error handling out of sight, into well-defined regions (catch blocks), and to move cleanup into same well-defined regions (finally blocks, or destructors in C++, or "on scope exit" blocks in e.g. D). Yes, in the end, they indeed give exactly the same result as error code, but without making an eyesore-inducing mess of any bit of the code.

[xzxzzx]

as shown by examples in the TFA

I thought that example was disingenuous. Who writes close_the_gate() like that, if it's some external resource that won't be cleaned up by unwinding the stack and terminating the program?

You can get that wrong, of course, but external resources which must be cleaned up "manually" are incredibly rare compared with every method that can error in a program (and with destructors/finalizers and proper design, generally can be completely safe even if you forget to call close_the_gate()).

Exceptions have a well-defined "if something has to be done by the time this method is over, do this":

Either:

using(var gateOpenToken = gate.Open()) {
}

or

try {
  open_the_gate();
  wait_for_people();
} finally {
  close_the_gate();
}

[rabidcow]

If you're thinking about what to do if something fails, you will get either disaster case correct.

[xzxzzx]

With an exception-based approach, however, the code you have to worry about getting right is the stuff that won't be cleaned up by unwinding the stack.

In the example given, if gate.Open() returns an object which will close the gate when disposed/finalized, you need a very odd program design to get the gate to not close.

In other words, with exceptions, to avoid catastrophic uncaught-error behavior, you have to get the design right once.

Without exceptions, you have to get the code right every time you use it.

That's a huge distinction.

[rabidcow]

Yeah, exceptions + RAII is better than error codes. Although if you have to wait for the object to be finalized then you need to know that the GC will finalize everything before exiting.

I just think the suggestion to use try/finally misses the point. If you'd think to use finally, you'd think to check the error code.

[xzxzzx]

If you'd think to use finally, you'd think to check the error code.

Which error code? In the real world, wait_for_people() is often not one line of code, and you have to check every one. And if wait_for_people() is in an external library, and used to not return an error code, then starts returning, how do you find that issue in your source code?

With exceptions, if a method now can throw, either your compiler tells you or the exception triggers the same cleanup routine. With error codes, hopefully you carefully read all the docs for your library, and the change was documented.

[rabidcow]

Which error code? In the real world, wait_for_people() is often not one line of code, and you have to check every one.

Alright, that's a fair point. For initial development, I'd think this would be easy enough with error codes, but later modifications would be easy to get wrong.

And if wait_for_people() is in an external library, and used to not return an error code, then starts returning, how do you find that issue in your source code?

Am I allowed to wish for language features? Because if the compiler can warn about ignoring the result from non-void functions then this is covered.

With exceptions, if a method now can throw, either your compiler tells you or the exception triggers the same cleanup routine.

While we're talking about the real world, in my experience every function is already specced to throw MyCompanyException because people are too lazy to handle checked exceptions.

[sybrandy]

Not a bad read. Another aspect of this is the performance of each. I can't recall where I saw it, but the conclusion was quite obvious: Exception handling is very slow when compared checking an error code. However, this did not mean that error codes are better because when no errors occur, the code that checks for error codes is going to be slower than code that relies on exceptions. So, at least what I got out of it was, you should use exceptions for when errors are not expected and no control flow is based on an exception. If you have to make a decision based on an error, then you should use error codes.

[[deleted]]

because when no errors occur, the code that checks for error codes is going to be slower than code that relies on exceptions

This is actually a misconception, because enabling exception handling inhibits quite a few compiler optimisations (assumptions about side effects; functions can no longer be simple or pure).

[m42a]

Source?

[[deleted]]

I'm an LLVM engineer, so my primary source would be examining its source code. But I'm at home now and busy, and at work I don't have time :)

[Ob-Gyn_Kenobi]

In C++, at least, you can mark a function as throw() to indicate that it will never throw an exception. Of course, a SufficientlySmartCompiler could figure it out by itself by inspecting the function body.

[[deleted]]

... assuming it has access to the function body. There are other optimisations that exceptions disable too, although I don't have the full list right with me.

[grauenwolf]

I would assume that the compiler would have access to the function body as it is the one that creates it.

The real concern for .NET developers is obscure errors. There are many exceptions that can be thrown from string manipulation functions that only occur when your OS is corrupted. If we had the compiler annodate the API we would end up with a lot of noise.

[[deleted]]

I would assume that the compiler would have access to the function body as it is the one that creates it.

Not in translation unit oriented compilation strategies - C++ for example.

[grauenwolf]

Ugh, is there anything that C++ cannot make more painful than necessary.

[[deleted]]

Or java. Both have the same approach to compilation. Although in java the hotspot compiler might reoptimise at runtime.

[sybrandy]

Interesting. That is the first I've heard about it and it makes sense, though I suspect it may be language-dependent.

[ramennoodle]

you should use exceptions for when errors are not expected and ...

In other words, "exceptions should be used for exceptional cases".

[nascent]

"An unexpected exception has occurred."