oshaboy Yknow I like Raku but I wish there was a way to say "actually I don't want the string to be Unicode normalized" 00:07
nemokosch out of curiosity, what is your use case? 00:19
02:28 hulk joined 02:29 kylese left 02:41 SmokeMachine left, SmokeMachine joined
Voldenet re > stackoverflow.com/questions/516441...9#79892319 02:42
I don't overly hate idea, but it makes code really verbose 02:43
I've tried that a few times and overall Result<T, Error> needs good syntax support 02:45
02:47 skaji__ left, skaji__ joined
Voldenet but I suppose something like this would be pretty neat: 02:47
Hm, nevermind, I thought about using .resume with value but it ended up being really convoluted 02:48
overall probably there's no need to complicate this 02:55
m: sub some-fail { die "random" }; sub x { CATCH { default { return 42; } }; return some-fail() }; say x()
camelia 42
nemokosch well I don't like this more but for sure it does less 02:56
the truth is, I can entertain the task but in general I think it's massive code smell if you are ever going to need to do something like this 02:57
providing separate defaults for separate unusual code paths
Voldenet it totally isn't – having default value if something is not responding right is sane 02:58
nemokosch that is sane - having different defaults on different kind of problems is insane
02:58 cpli left 02:59 cpli joined
Voldenet actually I've used that and it's not horrible 02:59
nemokosch I'm not sold for sure
Voldenet # sub do-request { CATCH { when DeserializationException { return http-error(400) }; when ConnectionError { return http-error(500); }}; return http-json(200, do-request()); } 03:01
that might have some typos but you have the idea
ofc it's also possible to do that…:
# sub do-request { CATCH { when handle-error($_) { $_.http-format }; }; return http-json(200, do-request()); } 03:02
nemokosch it's almost like this is a good reason to not use exceptions but failures at the very least
Voldenet Failures don't have stack trace though 03:03
it's hardly ever a good idea to not have stack
or rather - error has to be very local
nemokosch well, you either want to use something as a value, or troubleshoot it, but not both at once
here, it seems that you want to use it as a value and you don't need a stack trace - you don't even need custom control flow 03:04
just a special value
Voldenet but then do-request doesn't have to bother with understanding all the errors
it just does regular golden path with "die" when necessary 03:05
nemokosch I don't understand
Voldenet > my $db = db-connect; LEAVE $db.try-disconnect; return $db.get-item($request.int-from-post<id>) 03:06
that'd be code of some method 03:07
and all of these methods can throw 10 exceptions
socket connection, dns resolution, timeouts, wrong request
or rather, deserialization error 03:08
when writing that you don't want to handle errors on-site because request would be failed anyway… but you don't want to hardwire the code to return HTTP codes
nemokosch none of those seem to be recoverable
I still don't see this middle ground where by default you'd still want to propagate but cherry-pick some to return values 03:09
Voldenet Well, connection error and friends should be 500 - server error 03:10
nemokosch also, at this point I can't see the big win
Voldenet but deserialization error would be 400
failure to find item would be 404
nemokosch in my solution, you still have the exceptions, it's just the "catching" is the default behavior
Voldenet however it's only responsibility of http, not the internal method that gets the item
nemokosch and the "rethrowing" is the manual part
also, you avoid the sub wrapping and the phaser 03:11
to my understanding, my version also doesn't need manual propagation on all levels of the call stack, only one rethrow - specifically needed because some exceptions were handled on that level 03:13
not just handled but "recast" as values
03:15 hulk left, kylese joined
Voldenet well, you can't handle one specific error and not others 03:16
nemokosch how not?
Voldenet m: class X is Exception { }; my $result = do given try { die X.new }, $! { when *, X::AdHoc { "Some other exception thrown: $_[1]" }; default { "Proper value: $_[0]"; } }; say $result
camelia Use of Nil in string context
Proper value:
in block at <tmp> line 1
nemokosch okay, this is hard to read 03:17
but if I get the idea: this can be addressed by one line of code
and it's a constant one line
Voldenet + you get to choose which errors are handled and which should be thrown further 03:19
for completness 03:20
m: class X is Exception { }; my $result = sub n() { CATCH { when X::AdHoc { return "bar" }; }; die "blah"; }(); say $result
camelia bar
Voldenet m: class X is Exception { }; my $result = sub n() { CATCH { when X::AdHoc { return "bar" }; }; X.new.throw }(); say $result
camelia Died with X
in sub n at <tmp> line 1
in block <unit> at <tmp> line 1
nemokosch well, you get to choose that either way, don't you 03:21
this is not a difference