[01:22] *** guifa_ joined
[01:24] <guifa_> what's the best way to error out on routines?  I see the MVM_exception_throw_adhoc() but want to make sure there isn't something potentially better to call

[01:25] <guifa_> in this case, it's something that would be good to eventually catch in Raku-world to give a good user message

[02:30] *** guifa_ left
[02:36] *** guifa_ joined
[03:51] *** guifa_ left
[04:57] *** Geth joined
[04:57] *** lizmat left
[04:59] *** lizmat joined
[07:32] *** librasteve_ joined
[08:03] *** vrurg_ joined
[08:04] *** vrurg left
[10:50] *** guifa_ joined
[11:34] *** guifa_ left
[14:55] <Voldenet> MVM_exception_throwobj exists, but you'd need to instantiate an exception somehow – it doesn't sound like a good idea

[15:38] <timo> we have a few options, I think. one of them is to invoke code that the HLL stored somewhere and putting the details of the desired exception in arguments, then the code from the hll creates and throws the exception object

[15:51] <timo> i'm not sure if we throw real exception objects in many places in moarvm

[15:54] *** sugarbeet left
[15:54] *** sugarbeet joined
[15:58] <timo> for AsyncTask we always have a "schedulee" and the queue it should get scheduled in, and we push an array with the schedulee and any options to that queue, and the schedulee is expected to take the arguments and differentiate between an error and success based on the arguments

[15:58] <timo> that's kind of like having the thing to call stored somewhere like i first described

[16:04] <timo> but whether that kind of approach is good or not depends on where you want to throw the exception from

[16:08] <Voldenet> such queue would need to have original stack trace and perhaps other low-level data available in that thread - to me it sounds like the code should put all the data in the expected structure exactly where it's throwing, it simplifies things

[16:09] <Voldenet> so perhaps it should allocate and initialize the expected exception

[16:10] <timo> well, that is for async I/O where work is done by the async I/O thread and there isn't a location or stack trace to send. instead, you're dealing with a Promise or Supply somewhere that handles all that for you

[16:11] <timo> the question is how to get the right type object and how to initialize its fields

[16:13] <Voldenet> yeah, this makes sense for async things where you can't expect to be in specific thread – but in any other context it would probably get in the way

[16:13] <Voldenet> depends on the context

[16:14] <timo> i didn't mean to suggest to clone the approach of having a queue

[19:14] <Voldenet> it would be nice if random code had ability to do `MVM_exception_throw_named(tc, "X::OutOfRange")`

