<SamantazFox>
I want to reuse that code snipped as much as possible, but the compiler doesn't seem to like it...
ur5us has joined #crystal-lang
<FromGitter>
<Blacksmoke16> whats the error exactly?
<SamantazFox>
Error: undefined method 'channel' for Invidious::Routes::API::V1::Channels:Module
<SamantazFox>
If you declared 'channel' in a suffix if, declare it in a regular if for this to work. If the variable was declared in a macro it's not visible outside it)
<SamantazFox>
Blacksmoke16 ^
<FromGitter>
<Blacksmoke16> think that latter part covers it. cant access a local var defined in a macro?
<SamantazFox>
but why it can't access it?
<FromGitter>
<Blacksmoke16> could prob just do something like `channel = nil` before calling the macro so its at least defined
<SamantazFox>
I have so many of those in the code now lol
jmdaemon has joined #crystal-lang
<FromGitter>
<Blacksmoke16> couldnt you just use a method that yields the channel?
<FromGitter>
<Blacksmoke16> or just a method that returns the channel instead of a macro
<SamantazFox>
problem is propagating that return in case of an error.
<SamantazFox>
I prefer to avoid functions that returns many different kind of data.
<FromGitter>
<Blacksmoke16> i think you could do something like this (sec)
<FromGitter>
<Blacksmoke16> eh what you have is prob fine
<SamantazFox>
ok ^^
<FromGitter>
<Blacksmoke16> is one of the things i dont like about kemal. Raising some exception would make all that a lot easier
<FromGitter>
<Blacksmoke16> which you could do ofc, but would be prob a non trivial change? :shrug:
<SamantazFox>
Blacksmoke16: I'm looking into it, tbh. There are many places in the code that would need better exception handling...
<SamantazFox>
But I'm worried how it would loook like on a large scale
<SamantazFox>
my main worry being HTML routes returning JSON, and vice-versa
<FromGitter>
<Blacksmoke16> yea would need something in place to know how to serialize the exception given the original request
<SamantazFox>
I'm vaguely looking into it. My ideas atm: 1) have a handler function for the various cases (HTML, JSON, etc...) and pass a proc with the actual function to run; 2) have a huge "catch all" handler and specific exception types for the various cases;
<SamantazFox>
I'm not yet sure what will scale the best
<FromGitter>
<Blacksmoke16> you have the negotiation component installed already. so really just need to map the mime type to a format, set that on the request somehow, then have some type that handles converting the exception into some common format depending on the format of the request
<FromGitter>
<Blacksmoke16> hardest part is if you need to render specific exceptions differently or something. otherwise if they all share the same format should be pretty doable
<SamantazFox>
Blacksmoke16: yeah, unfortunately different exceptions are handled differently. Some are ignored (we have fallbacks for that) some are informative for the user (simple "this channel is not available" message) and some provide a full stack trace...
<FromGitter>
<Blacksmoke16> handled differently is fine, long as the rendered output of them is somewhat standardized
<SamantazFox>
Uhh, well, it depends x)
<SamantazFox>
on the API side, yes, it's standardized
<SamantazFox>
On the HTML front-end side, that more complex
<FromGitter>
<Blacksmoke16> yea thats fair, not sure how'd you handle that
<SamantazFox>
Maybe that'll come along the various rewrites
<SamantazFox>
At least, I'm happy of what the code looks like now ^^
<FromGitter>
<Blacksmoke16> 👍
<SamantazFox>
There's still some duplicate code to take care of, as well as monstruosities (community and comments) but other than that, it's good ^^
<SamantazFox>
My next big objective is redis, so you'll probably hear me then x)