#errors

Dave Cheney 27 Jan 2019 5 min read

Go 2 aims to improve the overhead of error handling, but do you know what is better than an improved syntax for handling errors? Not needing to handle errors at all. Now, I’m not saying “delete your error handling code”, instead I’m suggesting changing your code so you don’t have as many errors to handle. […]

goerror handlingerrors

Dave Cheney 12 Jun 2016 5 min read

A few months ago I gave a presentation on my philosophy for error handling. In the talk I introduced a small errors package designed to support the ideas presented in the talk. This post is an update to my previous blog post which reflects the changes in the errors package as I’ve put it into service […]

goprogrammingerror handlingerrorsstacktrace

Dave Cheney 26 Apr 2016 11 min read

This post is an extract from my presentation at the recent GoCon spring conference in Tokyo, Japan. Errors are just values I’ve spent a lot of time thinking about the best way to handle errors in Go programs. I really wanted there to be a single way to do error handling, something that we could teach all […]

goprogrammingerror handlingerrors

Dave Cheney 7 Apr 2016 2 min read

This is a thought experiment about sentinel error values in Go. Sentinel errors are bad, they introduce strong source and run time coupling, but are sometimes necessary. io.EOF is one of these sentinel values. Ideally a sentinel value should behave as a constant, that is it should be immutable and fungible. The first problem is […]

goprogrammingerror handlingerrors

Dave Cheney 25 Jan 2015 5 min read

In my previous post, I doubled down on my claim that Go’s error handling strategy is, on balance, the best. In this post, I wanted to take this a bit further, and prove that multiple returns and error values are the best, When I say best, I obviously mean, of the set of choices available […]

goprogrammingerrorsexceptionsmonads

Dave Cheney 23 Dec 2014 2 min read

The common contract for functions which return a value of the interface type error, is the caller should not presume anything about the state of the other values returned from that call without first checking the error. In the majority of cases, error values returned from functions should be opaque to the caller. That is […]

goprogrammingerrorsinterfaces

lukaseder 29 Aug 2014 1 min read

For many PL/SQL developers, this might be common sense, but for one of our customers, this was an unknown PL/SQL feature: Backtraces. When your application raises an error somewhere deep down in the call stack, you don’t get immediate information about the exact source of the error. For large PL/SQL applications, this can be a … Continue reading PL/SQL backtraces…

sqlbacktracedbms utilitydebuggingerrors