Exception type #24

New Issue

pca006132 · 2021-07-20T17:29:43+08:00

pca006132 commented

2021-07-20 17:29:43 +08:00

We forgot to talk about exception types previously (or I forgot to note it down). I think the idea is to avoid storing any references so we can safely clone to a special heap for exception objects? (otherwise we may end up with https://github.com/m-labs/artiq/issues/1491 if we don't clone into a separate space)

Should we require the users to inherit from a certain subclass for exceptions? This way we can easily check for such constrains.

We forgot to talk about exception types previously (or I forgot to note it down). I think the idea is to avoid storing any references so we can safely clone to a special heap for exception objects? (otherwise we may end up with https://github.com/m-labs/artiq/issues/1491 if we don't clone into a separate space) Should we require the users to inherit from a certain subclass for exceptions? This way we can easily check for such constrains.

lriesebos commented

2021-07-20 23:30:49 +08:00

That is fine for me, though I have one request: to leave the NotImplementedError in such a way that it results in a compile error. This is currently the case and is quite useful.

That is fine for me, though I have one request: to leave the `NotImplementedError` in such a way that it results in a compile error. This is currently the case and is quite useful.

Sign in to join this conversation.

No Label

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/nac3-spec#24