Note that this kind of error masking doesn't need to be done in the same package as the base error package. I made a little standalone package <http://godoc.org/github.com/natefinch/filterr> that does it, we could do something similar if we wanted to keep the error package simpler (which is always a good thing).
On Thu, May 29, 2014 at 3:16 PM, Nate Finch <[email protected]> wrote: > What Roger is talking about, is when an error is implementation-specific > and may change if the implementation changes. > > For example, if you have a black box service that saves data, it might > write to the network or it might write to a filesystem, but where it saves > is an implementation detail. Let's say in the current implementation, > Save() returns a FileNotFoundError if you haven't called Initialize() > first, then people may write code that handles a FileNotFoundError by > calling Initialize().... now if you change the implementation to write to > the network, so now if they haven't called Initialize(), you return a > NetworkNotFoundError in the same situation.... their code will break. If > you had instead written your own error, or just masked the type of the > error to something generic, then they wouldn't have been able to write > their code that makes bad assumptions. > > Note that this is the most simple case of the problem. In reality, it can > be that some sub-sub-sub package was returning that specific error, and > your code had no idea, it just passed it on up unchanged. This is where it > gets insidious, because *your* code didn't change. Some dependency of a > dependency changed that you might not even realize you were calling. And > now people using your code are broken. If you masked all returned errors > except the ones you explicitly wanted to return, then this couldn't happen. > > > > > > > On Thu, May 29, 2014 at 3:00 PM, Jeroen Vermeulen < > [email protected]> wrote: > >> On 2014-05-29 09:50, roger peppe wrote: >> >>> On 29 May 2014 04:03, Tim Penhey <[email protected]> wrote: >>> >> >> Errors are worth treating specially here because they're >>> they pass up through multiple layers, so it's very easy to break >>> abstraction >>> boundaries by relying on specific error types. I believe it's very >>> important >>> to *think* about the possible errors that can be returned from a given >>> function, and not just throw up our hands and say "you guys 5 layers >>> down, >>> why don't you just communicate *arbitrary stuff* to the guy 3 layers >>> above". >>> >> >> It may help to consider this as two problems. >> >> >> One: caller needs to know about a specific failure — e.g. because it's a >> failure to the callee but not to the caller. Definitely part of the >> contract. You either: >> >> (a) define a super-specific error (exception class, error code, etc.), or >> >> (b) document that standard error X means failure Y in this case, and the >> caller picks up the error as close as possible to its origin. >> >> With these errors you have to make sure that the information isn't >> diluted as it propagates, but usually you don't have to take it too far up >> the call chain. >> >> >> Two: a caller can deal better with some errors, given more detailed >> information. You can help by attaching more information to the error >> (tags, taxonomy, properties) but only on a best-effort basis. You accept >> that you don't know exactly which errors can come out of the code further >> down. >> >> For example, if you're writing code which speaks to another program over >> the network, you may want to know: is this connection still usable? Do I >> know what happened to the operation I requested? Were we able to connect >> in the first place? Am I doing something that shouldn't ever work, such as >> mis-spell a command? >> >> With these errors you act on the best information you have, but you can >> always just fail. >> >> >> Jeroen >> >> >> -- >> Juju-dev mailing list >> [email protected] >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> mailman/listinfo/juju-dev >> > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
