Views on Error Handling
dannas.name
dannas.name
There are no errors, just unnecessary abstractions and control flow hacks. You try to open a file; either you can or you cannot, and both possibilities are equally likely and must be handled by normal control flow in your program. Forcing an artificial asymmetry in the treatment of both cases (as championed by the error handling people) adds ugly complexity to any language that tries to do so.
You can use exception or Result depending on when it makes the most sense and this is the best of both worlds. https://github.com/kittinunf/Result
data = open("/var/foo")
Historically, a failure might just set 'data' to an invalid value (like 0 or null) but that ended up being a bad idea. And we needed some way to return more information about the error. So we started doing this:
error = open(data, "/var/foo")
Then exceptions were invented so we could use proper function call styles again, and the program wouldn't go into an undefined state. Instead, the error could be handled with separate logic, or the program would halt if it was ignored. This was far from a perfect solution, though.
Then sum types entered the mainstream, so 'data' had well-defined ways of returning something other than the expected result. But that resulted in a lot of competing conventions and stylistic decisions for what to do when 'data' is an error type, that haven't quite been settled yet.
data, err := open("/var/foo")
if err != nil....
It's all rather abstract, I guess, but yesterday I found an example while playing a game, "Opus Magnum". You are to solve puzzles by arranging mechanical arms to move marbles. Initially I mentally referred to actions of the arms as "taking a marble" and "placing a marble" and solved quite a few puzzles this way. In all solutions all my arms did exactly that: they took and placed marbles without doing any purposeless movements.
Yet yesterday the next puzzle looked too tiresome to built. I had an eureka moment once I realized that the arms do not take and place marbles, they merely close and open their grips and if there's a marble, it gets caught, but the arms themselves have no idea whether they're moving a marble or not. And once I allowed myself to let them do "purposeless" movements without marbles, I found a simple and elegant solution :)
If you have a function called `Add` that takes 2 parameters and returns the sum of those two numbers. That's the operation. If the web service that you call to perform the sum is down, it cannot return that sum, so that's an failure.
The code that calls this function needs that sum to continue it's operation. If it cannot get that result it cannot produce it's own result and that error needs to be propagated. Maybe the entire program has a purpose that it cannot now be completed and should be aborted.
Joking aside, consider the following case. A function needs to print a series of reports and opens Print Setup. The user changes his mind and presses "Cancel". Now the function cannot continue and needs to stop the planned operations, undo what it has done so far, and return control to the user.
The internal mechanism you're going to use for this will be most likely the same mechanism you use to handle errors. But what you're handling is not an error, at least in the common usage of the word, because nothing erroneous is happening! Everything goes exactly as should and according to the general purpose of the application.
My point is that the current dichotomy of success and failure does not help us to solve the seemingly simple problem of errors.
Which is exactly how exceptions work. If you're using RAII or similar pattern in your language there is no separate path for cleaning up errors than from the normal cleanup. That's the point actually. If the user presses cancel or an exception is raised the eventual stack unwinding will undo everything.
If you have a bunch of conditional statements for every possible error, you're actually creating more situations that are unique for errors. You have all these paths to test for. With exceptions there is only the happy path both in the operation and the cleanup.
Disagreeing is alright, but here you don't really do, do you? I can translate the paragraph you have written into pseudocode:
> If that operation requires the contents of the file, then the program cannot continue unless it successfully reads the contents of the file. (...) If you cannot open the file, there isn't any more to do.
if (file opening fails):
stop doing things
else:
continue with your operations
This is what we call raising an exception.
> I add that the desired behavior can always be implemented using regular control flow constructions.
I agree. But that's not a very interesting observation. We added language specific constructs for errors not for the computer but for the human. These constructs make reading and writing code easier and safer.
A code with if-else constructs for every possible error condition is really hard to follow and very brittle. If the result of every error condition is the same (stop doing things) we have developed constructs to make that path easy.
The problem with errors is that understanding and resolving them is often non-local. If a network call fails the code where that fail happens doesn't have enough information to resolve it. If the solution is re-try the entire operation 3 times and then give up, the handling of this error must happen back where the operation starts not some random place in the middle where it actually occurred. Maintaining all the if/else necessary to move that information up through potentially dozens if not hundreds of calls is extremely difficult. And, it turns out, completely unnecessary and easily automated.
Each library/system call you do can result in a set of possible consequences. We usually don't care about them equally, though: in fact, in the file example, 99% of the time we care about whether the file was opened or not - and in the latter case, we don't need to know why. So the asymmetry is already introduced by the intent of the program - there's usually only one path of execution we want; other ones are distractions. Error handling exists to express that asymmetry of caring at tool level.
See https://news.ycombinator.com/item?id=23843525 for a recent long discussion about my upcoming book on the topic. (Disclosure: this is a shameless plug.)
Broadly speaking, conditions can be implemented as a library feature, so you can reintroduce such things in cases where the extra functionality is compelling (though now users won’t be familiar with it, so it’ll be much harder to justify).
Other programming languages have been tending in the direction of implementing generators and async/await, which can be used to more smoothly implement some of the key concepts of conditions. (They’re not the same by any means, but related.)
I'll take the time to read up on it properly, but from a quick glance it seems to me to be in the category of non-local transfer of control with a co-routine flavour.
It looks powerful, but I get the sense that a lot of language designers are on purpose trying to restrict the powers of error handling. So returning sym types or error codes are simpler than throwing exceptions which - again looks to me - to be simpler than allowing transfer of control to be decided at run time as in the condition system.
Again, very interesting. And thank you for making me aware of its existence.
Kind-of-but-not-exactly. There are no coroutines whatsoever; the main technical defining point is that the stack is not unwound when the error happens, but it is wound further. Some code is executed that then searches the dynamic environment for matching error handlers, which are executed sequentially; these are then capable of executing arbitrary code provided from earlier in the stack in form of invoking so-called restarts; both handlers and restarts are also capable of performing transfers of control to any point on the stack that was properly annotated as being available for such.
Signed, the author of that book. :)
I.e. I don’t care about restoring the program to a known state when handling an error (memory deallocation is just one case of processing unwind blocks; locks need releasing,my file handles returned to kernel etc). This really only makes sense when your error “handling” is merely printing a user friendly error message and exiting.
I have never used setjmp/longjmp myself. And I agree with you that my first instinct would be to use it in the similar manner as in many GUI programs: they have have a catch statement in the message loop that shows a dialog box of the thrown exception. You just jump to a point where you print a user friendly error message and exit.
But I still can imagine use cases where you've isolated all other side effects (locks, shared memory, open file handles) and are just dealing with a buffer that you parse. Has anyone used setjmp/longjmp for that around here?
Given your many years in the field and Cygnus background I guess you've used it a few times? Do you happen to have any horror stories related to it? :-)
Think about how it works: it copies the CPU state (basically the registers: program counter, stack pointer, etc). When you longjmp back the CPU is set back to the call state, but any side effects in memory etc are unchanged. You go back in time yet the consequences of prior execution are still lying around and need to be cleaned up. It's as if you woke up, drove to work, then longjmped yourself back home -- but your car was still at work, your laptop open etc.
Sure, if you're super careful you can make sure you handle the side effects of what happened while the code was running, but if you forget one you have a problem. Why not use the language features designed to take care of those problems for you?
This sort of works in a pool-based memory allocator.
The failures happen three ways: one is you forget something and so you have a leak. The second is that you haven't registered usage properly so have a dangling pointer. Third is by going back in time you lose access to and the value of prior and/or partial computation.
If you use this for a library, and between the setjmp and longjmp is entirely in a single invocation you can sometimes get away with it. But in a thing like a memory allocator where the user makes successive calls, unless you force the user to do extra work you can't be sure what dependencies on the memory might exist. If your library uses callbacks you can be in a world of hurt.
Trying to keep track of all those fiddly details is hard. C++ does it automatically, at the risk of potentially being more careful (e.g. deallocating two blocks individually rather than in one swoop -- oh, but that language has an allocator mechanism precisely to avoid this problem). The point is the programmer doesn't have to remember anything to make it work.
When I use setjmp/longjmp error handling I almost always want abort semantics but at the library level rather than at the OS process level. [1] Where applicable it's the simplest, most robust model I know. You have a context object that owns all your resources (memory blocks, file handles, etc) which is what lets you do simple and unified clean-up rather than fine-grained scoped clean-up in the manner of RAII or defer. You can see an example in tcc here:
https://github.com/LuaDist/tcc/blob/255ba0e8e34f999ee840407c...
https://github.com/LuaDist/tcc/blob/255ba0e8e34f999ee840407c...
[1] It goes without saying that a well-written library intended for general use is never allowed to kill the process. This presents a conundrum in writing systems-level C libraries. What do you do if something like malloc fails in a deep call stack within the library? Systems-level libraries need to support user-provided allocation functions which often work out of fixed-size buffers so failure isn't a fatal error from the application's point of view. You'd also want to use this kind of thing for non-debug assert failures for your library's internal invariants.
This style of setjmp/longjmp error handling works well for such cases since you can basically write the equivalent of xmalloc but scoped to the library boundary; you don't have to add hand-written error propagation to all your library functions just because a downstream function might have such a failure. I'm not doing this as a work-around for a lack of finally blocks, RAII or defer statements. It's fundamentally about solving the problem at a different granularity by erecting a process-like boundary around a library.
I can see some minor corner cases where it could be worthwhile but the mental overhead isn't worth it.
I've written plenty of realtime code but spending a lot of time on the code running in the interrupt handlers is mentally exhausting and error prone; I do that when I have no choice. Likewise I've written a lot of assembly code but it's been decades since I wrote a whole program that way -- I don't have enough fingers to keep track of all the labels and call paths.
E.g. just because c++ has pointers doesn't mean I use them very often. >90% of the cases can be references instead.
That is only a superficial level of composition, if one can call it that at all, that doesn't account for actual composition of errors of different types. The example provided is just encapsulation and therefore orthogonal to the issue of error handling approaches. i.e. in the example, the error handling code is only centralized, not composed.
Do you mean the fact that there must be some if-statement within the API that reacts to the different errors and sets a flag used by the Err() method?
Is you opinion that "composition of errors" always requires special syntactic elements such as the match statement?
The code from the blog section:
scanner := bufio.NewScanner(input)
for scanner.Scan() {
token := scanner.Text()
// process token
}
if err := scanner.Err(); err != nil {
// process the error
}Maybe I'm naive to how exceptions are actually implemented, but it seems to me that both a checked exception and Sum Type would incur the same overhead, a single branch to make sure things haven't exploded.
Essentially, I would argue that error signaling is important enough and common enough that it deserves attention by the compiler in the same sense that many of the other things we provide syntax for (such as traits or inherentence) are things which developers can type naive manual implementations of with basic tools (such as switch statements or dictionaries or dragging around lots of function pointers), but if you can abstract it in a way such that the semantics are available to the compiler you can come up with much better ways to handle the problem (such as vtables or polymorphic dispatch caches) for a given set of tradeoffs (such as low memory usage, low construction cost, consistent latency, etc.). If everyone is implementing the feature themselves manually in the code then you have lost any real ability to make great optimizations.
(Note that you don't necessarily have to have it be syntax to do this: you can also have a language such as Haskell--where notably these Either-style errors are usually cited as being from--where they do it in the language but abstracted everything an additional level higher, letting you define a lot of these flow control concepts in terms of a monad, so then downstream users use "do" notation to feel like custom syntax and the monad's bind operator provides a central chokepoint on what was otherwise a bunch of boilerplate. You sometimes--not always--can then do optimizations across the entire program of that shared abstraction. The way languages like Rust and Go are handling this, without support for monads, simply precludes anything other than attempts at reverse engineering semantics from the code, which is ridiculous.)
* The exceptional path is slow (00:10:23). Facebook was using exceptions to signal parsing errors, which turned out to be too slow when dealing with loosely formatted input. Facebook found that using exceptions in this way increased the cost of parsing a file by 50x (00:10:42). No real surprise here, this is also a common pattern in the Java world and clearly the wrong way to do it. Exceptions are for the exceptional. * Exceptions require immediate and exclusive attention (00:11:28). To me, this is a killer argument for errors over exceptions. With exceptions, you can be in your normal control flow, or the exceptional control flow, not both. You have to deal with the exception at the point it occurs, even if that exception is truly exceptional. You cannot easily stash the first exception and do some cleanup if that may itself throw an exception.
You can stash/rethrow exceptions since c++11 with an exception pointer if you really need to.
Swift does this by default! You have to annotate (via @discardableResult) those functions which should not warn.
But of course try/catch is used in Swift more often.
While I have your attention: A big thank you for Fish shell!
And related to the current subject: How does fish handle errors? A quick skim found some constants that are returned upon failure, such as this case for disown: https://github.com/fish-shell/fish-shell/blob/master/src/bui...
What trade-offs did you face when designing error handling for your shell?
Shells are rarely CPU bound, so some perf overhead is acceptable. But shells may be used to recover badly broken systems. If fork or pipe fails, most programs are OK to abort, but a shell may be the user's last hope, so has to keep going.
For example, if pipe() fails, it's probably due to fd exhaustion. If your system is in that state, the best thing to do is immediately unwind whatever is executing, and put the user back at the prompt. fish uses ad-hoc error codes (reflecting its C legacy) instead of exceptions, though it uses RAII for cleanup. Your question made me realize that fish needs a better abstraction here; at least use `nodiscard`.
The story is different for script errors [1]. If the user forgets to (say) close a quote in a config file, fish will print the line, a caret, and a backtrace to the executing script. A lot of effort has gone into providing good error messages with many special cases detected. The parser also knows how to recover and keep going; I think Fabien would approve.
1: https://github.com/fish-shell/fish-shell/blob/225470493b3cd1...
I would be interesting to do a follow-up to this post where I compare the error handling for some common libraries/programs and ask the authors on what trade-offs the faced when designing error handling. It's a subject, I beliveve, that is often overlooked.
FWIW I find actual exception usage rare aside from automatic error out parameter to exception conversion by the Clang importer when bridging to Objective-C code.
- errors i.e bugs made by programmer - logical "error" conditions that the program is expected to handle for example network connection failed or user input failed - unexpected error conditions that typically boild down to resource allocation errors, socket could not be allocated or memory allocation failed etc.
In my experience all of these are best handled with a different tool.
For bugs use an assert that dumps the core and leaves a clear stack trace. For conditions that the program needs to handle use error codes. And finally for the truly unexpected case use exceptions .
And even for conditions that the program is expected to handle, 99.9% of the time all it can do is notify the user and ask for guidance, which means that the error must be bubbled up from a networking or storage layer all the way to the presentation layer - a perfect task for exceptions or something like an error monad.
The only problem with exceptions or error monads is that they get tricky in the presence of resources that need to be released, and even that is well handled with patterns like RAII.
If that one obscure code path corrupted my state, I want to limit the incorrect actions that the software takes based on that state.
This "want" of mine is to be balanced with all the other things I want out of the program, and the relative weights will vary by context... but it is often the case that continuing erroneously risks more harm than simply falling over.
Still, not all bugs have unbounded impact. As long as memory is not corrupted, thing like off by one errors and null pointer exceptions can often be safely recovered from by simply reverting the operation that hit the error until some kind of safe point (such as the last user interaction, or the last thread start).
Edit: spelling.
The answer is that just as a process has some degree of isolation from other processes on the same system, and from the kernel, similarly components of a process can be well enough isolated that only the specific component that encountered the bug needs to be stopped. This is never 100% safe, but how safe it is depends greatly on the technology and architecture.
That's the whole idea of exceptions. Give up on some chunk of what you were doing, and recover to a previous state.
This works best when you have some notion of a transaction, and can get back to the state before the transaction started. This is what "ROLLBACK" in SQL does.
Yes, that is exactly my point in favor of exceptions, or at least against stopping the whole program with a core dump.
People seem scared to dump core but I find that doing it makes my programs much robust and also simpler. I have no muddled logic to "deal with" bugs in the program itself. They simply will abort the program.
The process is one boundary of isolation, and you are making a bet that the corruption has not crossed this boundry. You can take the same bet with subcomponents of the process, just as in larger systems style may actually prefer to reboot the whole machine or even kill it and spin up another.
This all depends on the architecture and technology you are working with. If a user has input some bad data that I didn't think to validate (user inputs 11 in a page number field, when there are 5 pages in total), an operation is initiated on that data (user presses the 'go' button), and that operation is known to be stateless, when it encounters an error (ArrayIndexOutOfBounds), we can safely abort the operation, log the stack trace, and signal an 'internal server error' to the user without having to kill the whole process.
Not to mention, in a program with many non-transactional state changes, dumping core could be a source of persistent corruption in itself, if another thread was doing something as simple as, for example, writing a JSON file.
In other cases, even in Java, this may lead to corruption. For example, if we wrote that 11 into some kind of configuration file, we may have just corrupted the system persistently, even if we handle the error. So I'm not claiming that his is always a safe thing to do.
However, dumping core is also not safe a lot of the time. In fact, in multi-threaded processes, it can be argued that it is most likely unsafe to crash [as long as there is any kind of persistent state, such as a file] for the same reason interrupting a thread is inherently unsafe - there is absolutely no guarantee possible for what will happen if a thread is interrupted at an arbitrary point.
Danger of core dump in MT case is a valid point, though. However, one can argue that "unsafe to crash" is an indication of poor architecture decision - e.g. saving persistent state to file should be done by writing to new file first, and only replacing old file after that is completed (but I kind of agree, this may be hard to make 100% reliable)
P.S. on the other hand, looking on your other comments in this thread, I do agree with your point - yes, there are cases indeed when you have an assurance the error could not corrupt the state / propagate to other part of the program, then logging error and not crashing is a better option. That's rarely happens in my projects, but this is specific of what I'm doing, and does not invalidate the point.
I see from your replies what you're trying to say. If an error occurs, most likely you want the entire operation to abort -- that doesn't necessarily mean the whole program depending on the program.
For example, if I have a GUI app and the "save" operation fails and I typically roll that back right to the event loop of the application and the user gets an error and they can retry the save.
For other types of applications, killing the whole process is ending the operation.
And on the other end of spectrum, there are even systems where it makes sense to go further than killing a single process, and kill the whole container or even VM where a buggy condition was encountered.
Related, I always find it funny when C programmers write `if (malloced == NULL) return NULL;` Either you’re going to forget that this can happen and dereference null (in which case it’s just better to abort the program immediately) or the caller will check this and then close the program. If it doesn’t, the next malloc will be null anyways, and the problem repeats. Just call abort().
Of course the error handling story is still perfectible but so far it's already one of the best I know.
Two popular crates for handing these situations are thiserror [1] and anyhow [2], for handling errors by type and handling all errors, respectively.
There are additional ways, like just returning a Box wrapper around the stdlib error type [3], or just unwrapping everything. It depends on what your program needs.
[1] https://crates.io/crates/thiserror
[2] https://crates.io/crates/anyhow
[3] https://play.rust-lang.org/?version=stable&mode=debug&editio...
let value = unsafe {
match result {
Ok(value) => value,
_ => hint::unreachable_unchecked()
}
};
fn foo() -> (usize, Result<(),()>) { (0, Ok(())) }
let (a, err) = foo(); err?; // propigate error
let (b, _) = foo(); // discard error
fn foo() -> Result<usize> { Ok(1) }
fn bar() -> Option<usize> { None }
let val = foo().unwrap_or(3); // val == 1
let val = bar().unwrap_or(4); // val == 4
let mut line = String::new();
let _ = buf_read.read_line(&mut line);
// ...use line, even if there was an error...
// https://doc.rust-lang.org/std/ffi/struct.OsString.html#method.into_string
match os_string.into_string() {
Ok(string) => println!("Valid UTF8 string: {}", string),
Err(os_string) => println!("Invalid UTF8: {:?}", os_string),
}Community habits and language frictions matter a lot. In Go, doing the equivalent of `Result` requires custom private types for every combination, with private fields and accessor methods that protect against misuse. And you still only gain runtime safety. And they can still make a zero-valued var and use it without "initialization" (unless you use private types, which are an even bigger pain for a variety of reasons). Any other approach makes it trivial to bypass - public fields can just be accessed, multiple returns can be ignored, etc. In Rust, the community and language make `Result` common, and then you gain compile-time safety in most cases, and warnings in all others (AFAIK, as Result is annotated as "must use", so you get a warning or a `_ =` as a visible marker that you're ignoring something).
---
tl;dr multiple returns of course bypass this, but in practice you won't see that in Rust unless it's intended to allow ignoring the error. Underscores on out-param funcs are a good point, but they're also fairly rare / serve as a visual warning of shenaniganry.
let _ = something_returning_Result();
Just to clarify: the "let _ = ..." construct is the explicit way of suppressing the warning in Rust. You acknowledge that there is indeed a return value but you choose to ignore it. Just calling the function without explicitly discarding the Result will give you a warning.
> The Erlang Approach - Let it Crash