| 05:10 | <TrustInAllah> | I will post a video of a series of lectures on the Hereafter on what happens to us after this life, I know you're all busy with your works and this might be irrelevant to your interests but this is extremely important. Please pause whatever is you're doing and put it on hold as death is a reality which none of us can escape, https://www.youtube.com/watch?v=J6POzsLaKP4&list=PLyIDfFGMrsvtUiDND |
| 05:10 | <TrustInAllah> | 0bzdKagGyejGWYJU |
| 11:31 | <tobie> | Kind of confused as to what the right language is to fire error events. |
| 11:32 | <tobie> | Say I have a NotAllowedError DOMException, how do I turn that into an event and dispatch it? |
| 11:34 | <tobie> | Do I need to use the ErrorEvent interface and set each of its attributes to the corresponding ones in my DOMException object? |
| 11:35 | <tobie> | Or do I just only need to "fire a simple event named error"? |
| 11:40 | <annevk> | tobie: depends on what you want 😊 |
| 11:41 | <annevk> | tobie: latter is more typical I'd say |
| 11:41 | <tobie> | annevk: well, consistency with the rest of the platform |
| 11:41 | <tobie> | annevk: but the API consumer needs to be able to know why the event was fired |
| 11:42 | <tobie> | annevk: e.g. was permission denied or does the sensor not accept frequency above 250 Hz, for example |
| 11:44 | <tobie> | annevk: does "fire a simple event named error" actually allow any of that? |
| 11:46 | <annevk> | tobie: not really |
| 11:47 | <tobie> | annevk: OK, so I guess I'm not doing this the right way, then. |
| 11:52 | <tobie> | annevk: should I use an error attribute on the sensor object? |
| 11:52 | <tobie> | That seems really ugly. |
| 11:57 | <annevk> | tobie: you could define your own event class |
| 11:58 | <tobie> | annevk: oh, you mean like a DomExceptionEvent that takes a DOMException as argument and does all the things it needs to? |
| 11:59 | <tobie> | Wouldn't that belong at a lower layer of the platform, though? like in DOM? |
| 12:00 | <annevk> | tobie: hmm, depends on the requirements |
| 12:03 | <tobie> | annevk: well I guess the only requirement on my part would be for the API consumer to get the error through the error attribute of the event. |
| 12:05 | <tobie> | annevk: I'aware there are security issues about passing errors around, but I'm not well versed enough in the issue to see whether this would be a problem here. |
| 12:05 | <tobie> | *I'm |
| 12:06 | <tobie> | annevk: tbh, I'm kind of surprised you can't systematically reach an error object from an error event. |
| 12:26 | <annevk> | tobie: sorry, back tomorrow |
| 12:27 | <tobie> | np |
| 12:27 | <tobie> | annevk: it's Sunday, after all! |
| 16:57 | <annevk> | tobie: so mostly, I think that most APIs don't have the need for both exceptions and events modeling those exceptions |
| 16:57 | <annevk> | tobie: I think that if you have a need for that, you should just introduce something |
| 16:58 | <tobie> | annevk: I wrote it up like that: https://w3c.github.io/sensors/#handle-errors |