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

Jump to bottom

Different classes of embedding api errors have indistinguishable handles #4379

Closed
turnidge opened this issue Aug 6, 2012 · 10 comments
Closed

Different classes of embedding api errors have indistinguishable handles #4379

turnidge opened this issue Aug 6, 2012 · 10 comments
Assignees
@turnidge
Labels
area-vm Use area-vm for VM related issues, including code coverage, FFI, and the AOT and JIT backends. type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@turnidge
Copy link
Contributor

turnidge commented Aug 6, 2012

Currently there is no way to distinguish what caused a dart api function to return an error handle. If we had some way to do this, it would help.

Consider adding an enum of different error types...

type error
range error
null argument
not found
etc.

It seems like we will want the ability to distinguish these cases. It could also let us drop functions like Dart_IntegerFitsIntoInt64. Another use case would be distinguishing class not found from type error for Dart_GetClass. Developers who wish to handle an error must check for it eagerly to make the error signal unambiguous. That's a bit painful.

As part of this change we would need to list all possible errors for each api function in the docs.
@iposva-google
Copy link
Contributor

Added Accepted label.

@iposva-google
Copy link
Contributor

We should try to get the API clean before M1.

Added this to the M1 milestone.

@iposva-google
Copy link
Contributor

Removed this from the M1 milestone.
Added this to the M2 milestone.

@iposva-google
Copy link
Contributor

Removed this from the M2 milestone.
Added this to the M3 milestone.

@iposva-google
Copy link
Contributor

Removed this from the M3 milestone.
Added this to the M4 milestone.

@larsbak
Copy link

larsbak commented May 28, 2013

Removed this from the M4 milestone.
Added this to the M5 milestone.

@iposva-google
Copy link
Contributor

Removed Priority-Medium label.
Added Priority-Unassigned label.

@iposva-google
Copy link
Contributor

Removed this from the M5 milestone.

@turnidge turnidge added Type-Defect area-vm Use area-vm for VM related issues, including code coverage, FFI, and the AOT and JIT backends. labels Jun 5, 2013
@turnidge turnidge self-assigned this Jun 5, 2013
@kevmoo kevmoo added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) and removed priority-unassigned labels Feb 29, 2016
@iposva-google
Copy link
Contributor

@turnidge Is this still a concern? We have not had too many complaints about this from embedders, correct?

@turnidge
Copy link
Contributor Author

Well, nobody has ever complained about this. I'm going to close it and if we get an actual request for this feature then we can open it again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@turnidge turnidge

Labels
area-vm Use area-vm for VM related issues, including code coverage, FFI, and the AOT and JIT backends. type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@kevmoo @turnidge @iposva-google @larsbak