Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better error checking #41

Open
1 task
jarcane opened this issue Jan 11, 2016 · 1 comment
Open
1 task

Better error checking #41

jarcane opened this issue Jan 11, 2016 · 1 comment

Comments

@jarcane
Copy link
Owner

jarcane commented Jan 11, 2016

Developing in Heresy at the moment is a rather gigantic pain in the ass, largely because few of our functions have proper checks for bad inputs, and this gets further obfuscated by some of the levels of default abstraction now layered onto things.

I'm finding that a lot of trivial errors in particular don't get reported in their actual places, but somehow manage to throw strange errors in #%app way back in base.rkt, which is terribly unhelpful and often gives the mistaken impression of bugs in the main implementation.

For instance, calling slice$ with an out of index start point gives this rather unhelpful reply:

> (slice$ "[++--[+]]+" 0 8)
. . ..\private\base.rkt:397:31: cdr: contract violation
  expected: pair?
  given: '()

The long hard solution to this I think is simply going to mean going through each function and adding error checks and proper error calls for at least more common errors. This task, like the documentation task, will remain a perpetually open checklist. As I find more obvious errors that should be checked, I will update the following checklist.

  • splice/splice$ should check for less-than-1 index
@jarcane
Copy link
Owner Author

jarcane commented Aug 5, 2019

As discussed in #58, consider adding an error or at least a warning when a child thing overrides a field in the parent thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant