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

Compile-time error kills the current isolate #410

Closed
peter-ahe-google opened this issue Nov 10, 2011 · 5 comments
Closed

Compile-time error kills the current isolate #410

peter-ahe-google opened this issue Nov 10, 2011 · 5 comments
Assignees
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language).

Comments

@peter-ahe-google
Copy link
Contributor

The language specification does not say what happens when there is a compile-time error.

This is a quote from the obsolete language guide: "When a resolution error is detected, the entire isolate is destroyed and an error is signalled". In the specification, compile-time error is virtually the same as what the guide called a resolution error.

@gbracha
Copy link
Contributor

gbracha commented Dec 8, 2011

Yes, this is one of the unusual consequences of late detection of compile-time errors.


Set owner to @gbracha.
Added Accepted label.

@gbracha
Copy link
Contributor

gbracha commented Dec 15, 2011

I was about to add this to the spec, but decided to inquire with the VM team as to what exception is signalled, and to whom. It turns out the story is not so simple, as the isolate canot be destroyed before the embedder is notified (because the embedder may want to clean up resources etc.). Now the embedder is fact free to keep the isolate going (and might even have legitimate reasons for doing so).

So it may not be appropriate for the spec to warrant killing the isolate. I can also see the worry that we would have non-portable situations, where code behaved differently depending on the embedder. However, this would only arise wrt erroneous code (code that causes a compile-time error).

What we might say is that the execution of the isolate is suspended when a compile-time error occurs (so it's clear that the caller of an invalid function does not continue etc.).

Comments welcome.

@peter-ahe-google
Copy link
Contributor Author

I like this. One could also start a debugger and change the code and continue.

We also need to consider from a testing perspective. We need a way to test compile-time errors. Any thoughts on how we can test this?

Perhaps we can assume the following:

* in standalone/server mode, the VM will yield a non-zero exit code if the first isolate is suspended.

* in a browser, there will be a way to get notified if an isolate was suspended.

This way we should be able to test compile-time errors in all imaginable settings.

@gbracha
Copy link
Contributor

gbracha commented Dec 16, 2011

I like the debug story, but I'm not sure if it works. The stack is gone (well, maybe it's still in memory, but you don't know its extent). Needs discussion.

@gbracha
Copy link
Contributor

gbracha commented Jan 3, 2012

Fixed in 0.07 spec draft.


Added Done label.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language).
Projects
None yet
Development

No branches or pull requests

3 participants