forstmeier

// README
// This lives in the Apps Script editor on Google Sheets
// Three sheets "unsubscribers", "subscribers", and "email" required
// Email lists are updated whenever this script is run
// "un/subscribers" receive Timestamp/Email values from Google Forms
// "email" contains fields for writing/sending email to subscriber lists

function sendEmail() {
  var spreadsheet = SpreadsheetApp.getActiveSpreadsheet();

forstmeier

Overall, I'm in support of the suggestions being made in the draft discussions regarding inspection using the proposed Unwrap method. They seem to generally be in line with what I'd expect from Go. I'm in favor of not including the errors.Last for the reasons stated in the Open Questions and I think Unwrap is a fitting name for that method.

However, I'm less comfortable with errors.Is and errors.As. I think they could be useful, particularly in the way they are demonstrated in the draft, but I'm more concerned as to the actual internal implementation. Given errors.Is uses a perpetual for loop to look through the chain and the if err == target { return true } could evaluate to true at any point along the chain, it would be unclear as to where exactly it found a match. The root error (or the first error) is typically the one that I'm most interested in as that was the initial source of the rest of the resulting chain. By adding in the for loop that covers every part of the chain, handling c

forstmeier

Personally, I've never really minded the bloat created by the use of the if err != nil { ... }. I've always liked the ability to see right there on the next line exactly what happens in the event of an error.

However, I do understand the eye strain created by many of these popping up in quick succession, particuarlly when calling many helper functions (e.g. anything to do with handling and processing files). In the event that this moves to a full proposal, I would absolutely support the need to continue to allow for the more verbose if err != nil { ... } option, but I wouldn't mind seeing the check/handle desgin be implemented.

One suggestion I would have is to create a bit more clarity at the cost of introducing a few additional characters. I don't really like the idea of when check is triggered it rolls back up through the handle statements - it seems like something that could get confusing when scrolling through longer files.

Maybe something like this could be an option:

func CopyFile