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

Error/Assertion wrapping #435

Open
ghostsquad opened this issue Jul 15, 2020 · 6 comments
Open

Error/Assertion wrapping #435

ghostsquad opened this issue Jul 15, 2020 · 6 comments
Labels
error reporting How the errors are handled (e.g. stack trace quality)

Comments

@ghostsquad
Copy link
Contributor

I'd like to be able to do something like this, similar to how Go lets you wrap errors.

local assertFoo():: 
  assert false : "nope!";
  true;

assert assertFoo() : "higher level operation failed";

This is related to google/jsonnet#415

@sbarzowski
Copy link
Collaborator

An interesting idea. I imagine we would show the whole "stack" of errors. How would a more realistic example look like?

If it was limited to assertions, like in the example, we could get away with this without changing the semantics. It would just be a nice way to present errors (the intermediate assertions are already a part of the stack trace btw).

@ghostsquad
Copy link
Contributor Author

Well, the problem right now, is that this doesn't actually seem to trigger the outer assert

❯ echo 'local foo() = (assert false : "inner"; true); assert foo() : "outer"; {}' | jsonnet -
RUNTIME ERROR: inner

	<stdin>:1:54-59	$
	During evaluation

@sbarzowski sbarzowski added the error reporting How the errors are handled (e.g. stack trace quality) label Jul 15, 2020
@sbarzowski
Copy link
Collaborator

Well, the outer assert shows up in the stack trace (the 1:54-59 part). It doesn't "trigger" per se, because there is an error while checking the condition.

BTW you can use -e option instead of echo sth | jsonnet -.

@sparkprime
Copy link
Collaborator

There are 3 use cases to consider:

  1. Testing that a library raises errors when it should do
  2. Augmenting errors from libraries with application-level context
  3. Switching to a fallback if an expression raises an error (dubious, but useful since we use errors to represent "missing" fields sometimes)

With that in mind, I've thought for a while that a proper catch construct is probably better than addressing each case separately.

@ghostsquad
Copy link
Contributor Author

Actually, since it's related. What's the difference between assert and error? Is assert just short hand for if <cond> then error?

@sbarzowski
Copy link
Collaborator

Yes:
image

Object assertions are more than that and it causes a lot of trouble (e.g. google/jsonnet#451).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
error reporting How the errors are handled (e.g. stack trace quality)
Projects
None yet
Development

No branches or pull requests

3 participants