Permit DO to raise errors again #120
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When FAIL was conceived, it seemed that letting DO raise errors was encouraging of unclear practices. (DO X doesn't look like a failure or exception triggering mechanism if you don't know that X is an error, and it's not that great of a way of saying it even if it's clear that it is an error.) So DO of an ERROR! was turned into a different error than the one you asked for...instructing you to use FAIL instead. This was creating a bit of a bump, and likely an unnecessary one. If DO of an ERROR! is just going to give you an error anyway, it might as well give the error you asked for. However, THROW not allowing you to pass it an ERROR! is important and being kept. If THROW is used instead of FAIL (or DO) then it will confuse matters with TRAP, making it seem surprising that a thrown error could not be trapped. The message for trying to THROW an error helps to reinforce that you shouldn't use DO my mentioning not to use either THROW or DO (even though DO will now continue to work). Making the ergonomics a little easier, THROW of an ERROR! now puts the error as the argument to the "do not throw error!"...so you can read what it was *and* get an error, while still getting the advice.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When FAIL was conceived, it seemed that letting DO raise errors was
encouraging of unclear practices. (DO X doesn't look like a failure or
exception triggering mechanism if you don't know that X is an error, and
it's not that great of a way of saying it even if it's clear that it is an error.)
So DO of an ERROR! was turned into a different error than the one you
asked for...instructing you to use FAIL instead.
This was creating a bit of a bump, and likely an unnecessary one. If DO
of an ERROR! is just going to give you an error anyway, it might as well
give the error you asked for.
However, THROW not allowing you to pass it an ERROR! is important and
being kept. If THROW is used instead of FAIL (or DO) then it will confuse
matters with TRAP, making it seem surprising that a thrown error could
not be trapped. The message for trying to THROW an error helps to
reinforce that you shouldn't use DO by mentioning not to use either THROW
or DO (even though DO will now continue to work).
Making the ergonomics a little easier, THROW of an ERROR! now puts the
error as the argument to the "do not throw error!"...so you can read what it
was and get an error, while still getting the advice.