Begin drafting try/catch proposal

[mirisuzanne]

Based on #2619

Rough syntax (with the unit-testing use-case):

@try {
  $test: my.function('bad arg');
} @catch $error {
  @include true.assert-equal(
    $error,
    "'bad arg' is not a valid argument for 'function'"
  );
}

• resolve questions about what to catch, and how to shape it
• more background & use-cases
• finish the semantics

[chriseppstein]

Hey everyone, I've not been involved lately, but I hope you don't mind me swooping in and giving my thoughts on this proposal. I've always wanted to see @try statements in Sass, so I got excited by this.

The idea of catching a @warn is an interesting one, but also might be unexpected because @warn doesn't alter the control flow. I'd be interested to hear the use case(s) for this.

I have some questions about how @catch and @warn would interact:

1. Because execution continues following @warn, what would be the behavior if several @warn statements are encountered while executing TryStatements? I can imagine several possibilities: a) the first @warn statement is passed to @catch; b) The last @warn statement is passed to @catch; c) All @warn statements are passed to @catch. d) the @catch is executed immediately when the @warn fires and may be executed several times as if it were the body of a loop. If c, would the value of message be a list in the case a warning.
2. Given that execution continues for @warn, in the case of several nested @try ... @catch statements, does the @warn get passed to all of them or does it stop propagating unless "rewarned".

There's a use case around deciding that an error isn't the one you want to handle and rethrowing it. Given that an error message may have error specific values interpolated into the message that could be kind of tricky. What do you think about the idea of augmenting @error to have an identifier as well as a message? E.g. @error illegal-argument "Expected a string, got #{meta.inspect($arg1)}";. Then @catch could provide a discriminator so that only errors matching it are caught. E.g. @catch illegal-argument ($message) { ... }. Or the error object could have an extra key, etc.

When rethrowing an error, I think we'll want to preserve the original source location of the error. I think that might necessitate making a new data type.

If the main use case for using @catch with @warn is to silence a message do you think it makes sense to have a @try { ... } @silence ($warning) { ... } syntax where you can optionally inspect the warning and issue a new @warn if you want to print it out. In this case, should warn get a discriminator ident similar @error, seems like it would be handy for the same reasons.

[nex3]

Two nits:

• Production names should be capitalized (ExceptionVar not exceptionVar).

• Add a comment below explaining that no whitespace is allowed between '$' and Identifier. Or better yet, edit variables.md to have a PlainVariable that can be re-used without having to rewrite that caveat all over the place 😆.

[nex3]

I'm having a lot of trouble understanding this sentence.

[nex3]

I agree that catching warnings with this is unexpected. It's not how other programming languages work, and it may do very unexpected things with the control flow.

I'd like to punt on the question of how warnings are tested for now. It's much easier and safer to devise custom warning-capturing infrastructure, since you can just add strings to a list and you don't have to worry about globally coordinating return values.