<snusnu>
dkubb: because anything passed to the constructor, will end up in the new object
<snusnu>
dkubb: i could maybe patch the ice_nine hack to skip freezing of Environment instances in specs, but that's a hack too
<dkubb>
yeah, then you'd be testing behaviour that isn't actually like what the objects are at runtime
<snusnu>
yeah
<dkubb>
there are some cases where something happens inside an object but you don't have any direct way to observe it
<snusnu>
dkubb: if you look at that method again, you might say why i'd hate to stub it
<snusnu>
dkubb: it works on 2 instances of the same class
<snusnu>
dkubb: one injected, the other "anonymously" constructed
<snusnu>
dkubb: fwiw, i really like the design the way it is, i actually don't want to start a heavy refactoring because of this one mutant, same goes for stubbing the whole method
<snusnu>
hmmm
<snusnu>
the above should've read "see why i'd hate to stub it"
<snusnu>
dkubb: maybe i should add behavior to the app_env, and test some side effect of that
<snusnu>
yeah, that should work
<dkubb>
snusnu: are the @params docs on .build still correct?
<snusnu>
dkubb: oh, no .. i'll fix it, one sec
<snusnu>
dkubb: fixed
<dkubb>
so everything's private eh?
<dkubb>
based on the names of the methods it's hard for me to understand how they're supposed to be used. I was looking for @example sections, but I guess since they're all api private none of them have docs
<snusnu>
dkubb: you mean @api private ? yeah, for now .. for one, i'm lazy with writing examples, and, i don't yet know what will be public eventually
<snusnu>
dkubb: fwiw, that one is defintely @api public :)
<snusnu>
dkubb: what happens is, the registered processors get merged
cored has joined #rom-rb
cored has quit [Changing host]
cored has joined #rom-rb
<snusnu>
dkubb: so that the "union" of all the defined processors (defined inside the block) is available in the second, Web::ENV
<snusnu>
dkubb: the idea being, the core app, isn't concerned with the web, so it knows no :deserialize, or :render … you can use that for any sort of client, cli, whatever .. it's the "raw" app … but usable … then you plug it behind http .. so you define another substation environment, add a few processors, but build on top of the core substation env
<snusnu>
dkubb: with substation, you can layer everything on top of other by itself functional stuff, onion style
<dkubb>
I'm looking at the methods, and I see you have Environment.inherit, and the first argument is an Environment object. why isn't it an instance method on environment?
<snusnu>
dkubb: the actual toplevel substation api client code can be found in spec/demo/{core, web}.rb and spec/demo/{core, web}/facade.rb
<snusnu>
dkubb: lol, what a question … a really good one
<snusnu>
dkubb: it emerged out of only having Environment.build(other, …)
<dkubb>
I think what I noticed is this up/down/up/down pattern between the class and instance
<snusnu>
i should just make it an instance method of course, hah
<snusnu>
i have the instance already, *very* obviously
<dkubb>
you start with an instance, then you go to self.class.inherit and pass self in, then that method calls merge on the env, which then calls self.class.new
<snusnu>
thx so much
<snusnu>
seems like i got a bit lost somewhere deep within the refactoring frenzy
<snusnu>
:p
<dkubb>
I like to have a kind of boundary.. if I've got an instance I try to do as much as I can without going up to the class
<snusnu>
yeah, i tend to do that too, sometimes i fail, hard
<dkubb>
it's ok, it's hard to see when you're deep in something
<snusnu>
yeah, a 2nd pair of eyes is oftentimes worth a whole crowd of eyes
<dkubb>
I dunno if this is going to make it easier or harder to spec
<snusnu>
we'll see, it surely is nicer design
<dkubb>
but I think it's better to question if the structure is right before trying to make it work
<snusnu>
full ack
<snusnu>
heh i bet it'll also kill the mutant
<snusnu>
dkubb: thx so much, i will report back in a bit
<snusnu>
dkubb: i think so, because now i need to specify initial instance state
<dkubb>
sweet
<snusnu>
dkubb: it's KILLED
<snusnu>
dkubb: and the code is much simpler
<snusnu>
dkubb: flay score bumped by 8, lol, but yeah, it's simpler
<snusnu>
dkubb: now for another (new) last mutation :p
<snusnu>
dkubb: dead, all dead, finally
<snusnu>
:p
<snusnu>
dkubb: thx again for the tip!
<dkubb>
yay
<dkubb>
snusnu: sweet. what does the code look like now?
<snusnu>
dkubb: i will merge it soon, i'll have one final look over it
<dkubb>
snusnu: I'd be happy to look it over tonight and comment on it
<snusnu>
dkubb: cool, thx! i might merge it in before tho, if you don't have any objections (concerning your review flow)
<snusnu>
dkubb: you could still comment on the closed PR?
<snusnu>
dkubb: i might want to add a few other stuff i'm thinking of now
<dkubb>
yeah I could do that too
<snusnu>
dkubb: in particularly, mbj found a *bug*
<snusnu>
;)
<snusnu>
dkubb: if i keep committing unrelated stuff to that branch, it might confuse you? when looking over the complete diff i men
<dkubb>
I don't mind
<snusnu>
dkubb: well, lemme see what i can still do, i need to take a short break now anyway, maybe i'll not come back to it anyway
<snusnu>
dkubb: i only have a few more comparably minor things on my todo list for substation … might well be, that after those are done, i will come back to rom-dev more
<snusnu>
dkubb: your suggestion re .inherit => #inherit was a really good one .. the code initially evolved from only having .build .. on to accepting another env to build on top of: .build(other, …) …. after some time i found the "inherit" is a better name … and then i somehow missed that move to instance refactor opportunity
<snusnu>
dkubb: i somewhat relate that to the renaming … build is a "typical" class method, oftentimes .. once my head accepted that i'll build with class methods, even the rename to inherit didn't ring a bell
<dkubb>
no idea what "invalid fastbin entry" means
<snusnu>
dkubb: the fun thing is, it's gone now .. even more funny, it's gone within the same build
<snusnu>
dkubb: all green now
<dkubb>
heh
<dkubb>
snusnu: when you prepend two chains, can they have duplicate entries in the chain?
<dkubb>
snusnu: if so, would it make sense for prepend to do: other.processors | processors to eliminate dupes?
<dkubb>
s/if so/if not/
<snusnu>
dkubb: actually, i guess semantically that doesn't make sense … it'd almost be like calling the same method twice, where method is a complete processing step
<snusnu>
dkubb: so, lemme try that
<dkubb>
or would it make sense to raise an exception if there are duplicates?
<dkubb>
you could say that the two chains need to be disjoint
<snusnu>
dkubb: actually, yes, i guess that would make sense
<dkubb>
that is not contain any entries contained in the other
<snusnu>
hm
<dkubb>
I only wonder what'll happen if two chains have the same actions in different orders
<dkubb>
my guess is, in a typical app, you'd probably want to raise an exception if there are any dupes
<dkubb>
you can do: (other.processors & processors).empty? or raise ....
<snusnu>
dkubb: the "problem", if i see it correctly, also is that substation probably can't rely on all the injected client code to properly equalize? maybe it can tho? or it should even?
<dkubb>
but I dunno, I don't really have any deep knowledge of substation
<dkubb>
I'm not sure
<snusnu>
dkubb: the most easy way to think about substation, is that every "typical" processing step gets encapsulated in a single class, SRP ftw .. now if you were to do the same thing twice, within processing of one particular request (application use case), i guess that wouldn't make sense
<dkubb>
snusnu: so yeah, you'd want chains to be disjoint I'd guess
<snusnu>
dkubb: but yeah, enforcing disjoint chains would need to rely on proper equalizing
<dkubb>
ahh ok, that's what you're getting at
<dkubb>
I'm not sure if you could rely on equalization
<snusnu>
dkubb: i could do that tho, after all, i build it for myself mostly :)
<dkubb>
it depends on if you make it a requirement
<snusnu>
yeah
<dkubb>
I think concord gives you that for free
<dkubb>
equalizer does
<snusnu>
then again, a lot of the handlers you inject are actually somehow method objects
<snusnu>
i guess it might not make a lot of sense for them to be equalized, they're not really value objects
<dkubb>
I don't know if method objects equalizer. I think they may but not sure
<snusnu>
e.g. in every chain there'll be vanguards and ducktraps, deserializers and serializers, renderers, stuff like that
<snusnu>
equalizing those doesn't really come to mind as a first thing
<snusnu>
dkubb: all that said, currently Chain does equalize on its #processors, lol
<dkubb>
heh
<dkubb>
I don't think its an unreasonable expectation
<dkubb>
if the objects are kind of locked up procs with no ability to introspect, it's going to be hard to debug and extens
<dkubb>
what I do is run this like: vim $(~/alignment.rb spec | cut -d":" -f1 | sort -u)
<dkubb>
then I fix the busted specs
<dkubb>
I *really* don't expect anyone to do this. it's probably kind of mental that I do it myself
<dkubb>
snusnu: do you prefer 1.8 style hashes?
<snusnu>
heh, i would definitely not say mental .. tho i did feel mental myself back then .. because actually you know .. i did that *by hand* for far too long ;) .. then decided to accept solnic's preference which goes somewhat like, no :p
<snusnu>
dkubb: i probably wouldn#t say i prefer them, but i write them since 7+years
<snusnu>
;)
<dkubb>
for me the main thing is vertical alignment of assignment
<snusnu>
dkubb: and yeah, i don't really like symbol keys, then again that's almost a not-argument, cause i rarely ever use those
<dkubb>
it drives me crazy when I see a jagged line of assignment operators
<dkubb>
oh yeah, we're talking about hashes now
<dkubb>
that's interesting
<dkubb>
when I write literal Hashes I almost always use a Symbol as a hash key
<dkubb>
but I don't use it as much programmatically
<snusnu>
oh, i meant symbol values ;)
<dkubb>
oh yeah
<snusnu>
more precise, symbol keys and values
<dkubb>
this: :looks odd
<snusnu>
yeah
<dkubb>
but I don't do that too often
<dkubb>
maybe in the rename operator
cored has quit [Ping timeout: 264 seconds]
<snusnu>
yeah true
<dkubb>
but I shouldn't be doing tons and tons of renames in most cases
<dkubb>
unless my schema is f'd up
<dkubb>
but then I would configure the schema object to have sane names for everything
<dkubb>
in a real app, I may even opt to do some of the simplest mapping right in the schema
<dkubb>
like renaming attributes to be sane
<snusnu>
with rom apps, i think i will finally ditch the #id convention, and align it closer to what natural join likes
<snusnu>
new apps that is
<dkubb>
I think if you were working in a real app, on top of a legacy schema, you would want total isolation from the legacy schema. so you'd declare your axiom schema with renamed relations
<dkubb>
I may do that too
<dkubb>
so in a real app, my preference would be even if I had to drop down to writing sql.. or something sql-like, I would want sane names for everything
<snusnu>
yeah, that'd be ideal, i guess it gets hard when dropping down to sql, but with axiom, the nastyness should be hidden once and for all within the schema you interact with
jfredett has joined #rom-rb
<snusnu>
dkubb: i was thinking a bit more on what you said wrt renaming directly in the schema .. what if we would make that the default way to do it in rom? we would get consistency by doing so (mapped or not, the tuple attribute names are the same) .. and we could simplify the mapping DSL
<snusnu>
dkubb: it might make rom-mapper a bit less powerful tho, given that theoretically, it doesn't need to be used with relations
hammerdr has joined #rom-rb
jfredett has quit [Quit: Leaving.]
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
kapowaz has quit [Ping timeout: 240 seconds]
snusnu has quit [Quit: Leaving.]
hammerdr has quit [Quit: hammerdr]
kapowaz has joined #rom-rb
hammerdr has joined #rom-rb
<dbussink>
dkubb: we've seen that crash sporadically
<dbussink>
dkubb: but i've never been able to reproduce it anywhere :(
<dbussink>
dkubb: except for it happening on travis
<dkubb>
dbussink: fwiw, the travis guys can give you ssh access to a specific build
<dkubb>
at least we did with some work projects
<dbussink>
dkubb: ah, i asked about it and said they didn't really have a way to further debug :s
<dbussink>
i should ask again i guess
<dkubb>
yeah, we definately did get access
<dkubb>
we were paying, but they may make an exception because you're actually helping them
<dkubb>
it could be that we wore them down though. we had lots and lots of issues on the service before having to switch to circleci
hammerdr has quit [Quit: hammerdr]
<dbussink>
ah ok
<dbussink>
haven't had issues with more simple project actually
<dbussink>
been working fine for that
<dbussink>
but rubinius isn't the most standard project, but they've been very helpful
hammerdr has joined #rom-rb
solnic has joined #rom-rb
solnic_ has joined #rom-rb
solnic has quit [Read error: Connection reset by peer]
<solnic_>
dkubb: morning
solnic_ has quit [Client Quit]
solnic has joined #rom-rb
<solnic>
dkubb: still up?
solnic_ has joined #rom-rb
solnic has quit [Read error: Connection reset by peer]
hammerdr has quit [Ping timeout: 260 seconds]
knowtheory has joined #rom-rb
knowtheory has quit [Quit: Computer has gone to sleep]
<dkubb>
solnic: I think it can be supported. it would probably be done at the adapter level
<dkubb>
solnic: it would probably be more generalized though. server generated values might be a better way to think about it
<dkubb>
or rather adapter generated since what happens in the adapter is supposed to be a black box
<dkubb>
there's really nothing special about serial columns. it's just a default value generated by the server, no different from defaulting to an empty string for a string column, or 0 for an integer
<dkubb>
solnic: oh looks like you could use a blockargs mutator ;)
<solnic>
dkubb: hm?
<dkubb>
I just looked at the report at the end of mutant in your asciicast
<solnic>
it's mutant edge
<dkubb>
yeah I know. I use those reports to tell me what mutator to add next
<solnic>
dkubb: you know what, I don't think I like the #[]= interface
<dkubb>
solnic: why is that?
<solnic>
it forces me to write more code when using it
<solnic>
snusnu: wellll I did remove duplication :P
<solnic>
and if I needed this behavior in other places I'd move this into a module
<solnic>
there is already a module for that in axiom-types btw
<snusnu>
solnic: heh, #get_or_set … instance_variable_get … all for very very straightforward code otherwise
<solnic>
fix it however you like, I'm not going to spend more time on this
<solnic>
dkubb: rubocop crashes for me :(
<snusnu>
solnic: but well, i see the duplication removal, i dunno … i have no idea how to fix it otherwise, and won't spend time on it either, at least not now ;) i just wanted to mention that it doesn't appeal to my sense of aesthetics
<snusnu>
;)
<solnic>
I don't like it either man
<snusnu>
tbh, i would've been surprised :)
<snusnu>
i guess if it's really usable in multiple places, it's fine after all
<solnic>
snusnu: I was wondering about using memory adapter for development
<solnic>
thinking about what would be needed to really make it work
<solnic>
and realized we're completely missing support for server-generated key values :)
<solnic>
adding "serial" would be easy, but there are other more complex cases, quite db-specific so...not sure :)
<solnic>
oh wow travis is so slow
<solnic>
specs are running much slower than on my machine
<solnic>
it used to be the opposite
<solnic>
dkubb: why are we running metrics on 2.0 and 1.9????
<solnic>
I thought we decided to use 1.9 for develepment and metrics
<snusnu>
solnic: heh, good point re server-generated keys
<solnic>
snusnu: yeah so dkubb said it'll be easy to support that in axiom so...
<solnic>
we could start with serial
<snusnu>
solnic: i wonder if we should have some key factory like object, that we use, which will either get stuff from a backend, or provide an own implementation?
<solnic>
snusnu: yeah we should have something like that
<solnic>
it could be "compatible" with various key types
<snusnu>
solnic: say i just want (in memory) database wide unique keys, i should be able to inject some object that provides those
<snusnu>
yeah
<solnic>
like incremental integers, or some object ids like in mongo
<solnic>
we can add stuff as we move forward
<snusnu>
maybe, rom should always go through a dedicated api to get keys for any tuple/objects, if it doesn't get them back from the backend
<snusnu>
or maybe even axiom, for that matter
<snusnu>
so before instantiating tuples, it looks at what's supposed to be key, checks if it's not Undefined at this point, and if it's not, it uses it, and if it is, it fetches an appropriate key instance from some factory
<solnic>
yes sounds good
<snusnu>
it would probably mean a pimped key dsl, allowing to not only state the name, but also the factory
<snusnu>
but yeah, imo that could be pushed down to axiom
<snusnu>
so that rom only ever sees valid tuples
<snusnu>
if people use raw axiom memory adapter, they should still be able to define key factories as they please
<solnic>
snusnu: rom-relation passes rake ci...
<snusnu>
so awesome!
<solnic>
with yardstick threshold 90% :P
<snusnu>
fine with me
<solnic>
but the rest is done the hard-core way
<solnic>
full mut-cov, nice thresholds on flay/flog, reek is happy, rubocop too
<solnic>
and, what's most important, I am really happy with this code :P
<snusnu>
how many commits do you have left?
<snusnu>
:p
<solnic>
OH NOEZ
<snusnu>
awesome dude
<snusnu>
hehe
<solnic>
667
<solnic>
LOL!
<solnic>
dude
<solnic>
hahaha
<snusnu>
mwhaha
<solnic>
I cannot believe this!
<snusnu>
hah so cool
<snusnu>
it must mean *something*, right?
<solnic>
snusnu: you know what, actually my 666th commit is "Run rake ci on travis"...
<snusnu>
no way
<solnic>
and the 667th is only because I had to adjust flog threshold because I didn't know we run it on ruby 2.0.0
<solnic>
srsly
<snusnu>
lol
<solnic>
...!
<solnic>
:)
<solnic>
I did not do this on purpose, I swear :)
<snusnu>
hah, easy to say now tho
<solnic>
it's a total coincident :)
<snusnu>
:D
<snusnu>
solnic: i'm close to "finishing" substation for the time being, i only need a few more minor things … once that's done, in my freetime at least, i will get back to rom more and more
<solnic>
snusnu: cannot wait
<solnic>
also, need to try out substation
<snusnu>
i was thinking, maybe i should use rom in the demo integration app
<snusnu>
it will give an even more complete picture how substation can/should be used
<snusnu>
i would just implement a few simple actions on, say, 2 relations
<snusnu>
read/write
<snusnu>
and of course, write to views
<snusnu>
:D
<solnic>
cannot wait for people yelling "THAT'S SO OVERENGINEERED"
<snusnu>
yeah, that will be a good moment
<snusnu>
:D
<solnic>
totally
travis-ci has joined #rom-rb
<travis-ci>
[travis-ci] rom-rb/rom-relation#139 (master - 8912c84 : Piotr Solnica): The build was broken.
<solnic>
it's gonna be green unless rbx crashes on mutant
<solnic>
it shouldn't
<solnic>
snusnu: I need to tweak yardstick task to support sth like a min of coverage
<solnic>
now it's just too annoying
<solnic>
or even better, disable it completely
<snusnu>
solnic: hmm, actually i'm kinda on the side of dkubb here i guess … having good docs is not only for others, but also for ourselves … i do agree that documenting every private method seems a bit too much sometimes, but it's not a really big deal for me
<snusnu>
solnic: the most important thing would be to not fail the build while in topic branches
<solnic>
dude
<solnic>
my docs, written 2 days ago, are already outdated
<solnic>
fuck-this-for-now-seriously
<snusnu>
yeah i know, during heavy dev it's annoying
<snusnu>
hm
<solnic>
I want to have nice docs too, but I refuse REFUSE to waste time on writing stuff that gets outdated every week
<snusnu>
ok, i guess i'm fine with relaxing the yardstick rules, we must make sure everything is nice on release day tho
<solnic>
maybe after 0.0.1 things will calm down a bit
<solnic>
I will update stuff for public APIs for sure
<solnic>
prior the release
<snusnu>
i wonder, maybe we should just add a devtools config setting, ignore yardstick
<snusnu>
at some point it *will* be useful to have yardstick continuously perform its checks for every build
<solnic>
yes it will
<snusnu>
we just need to disable it for now
<solnic>
with a few tweaks
<snusnu>
or rather, we want to be able to selectively disable it, when we know it makes no sense
<snusnu>
i'm no fan of playing with thresholds either
<snusnu>
if it makes no sense to have it, don't run it
<snusnu>
not mess with thresholds, that gives a false impression
<solnic>
I have lots of complaints with docs, I need to put those thoughts together one day and explain
<snusnu>
it'd be a simple matter of adding enabled: false to our devtools configs
<solnic>
yes I want to have that option
<snusnu>
we know that we're gonna use it responsibly, for release, we adjust to sharp mode
<snusnu>
i agree with you, there's not much that is more tiresome than writing stuff you know will be out of data in a few days
<snusnu>
i often have that feeling with specs too
<solnic>
heh :)
<snusnu>
s/data/date obviously
<snusnu>
so yeah, i like integration specs heh, but let's not go down that road of discussion now ...
<snusnu>
we should have enabled flag in devtools configs
<snusnu>
agreed?
<snusnu>
the fun thing about the yardstick threshold also is, that it actually tells you *NOTHING* about the quality of your docs … every single one might be wrong, yet yardstick would be fine … i realize that we've been talking about some sort of tool that would make sure that this cannot happen ...
<snusnu>
it would be very very awesome to have
jfredett has quit [Read error: Connection reset by peer]
jfredett has joined #rom-rb
<solnic>
snusnu: oh yes, it would
<solnic>
snusnu: gaah looks like my get_or_set introduced an unkilled mutation :P
<cored>
which is the process to use it from source?
solnic has quit [Quit: Leaving...]
Gibheer has quit [*.net *.split]
dkubb has quit [*.net *.split]
shingara has quit [*.net *.split]
kapowaz has quit [*.net *.split]
kalleth has quit [*.net *.split]
jdsiegel has quit [*.net *.split]
xybre has quit [*.net *.split]
kpwz has quit [*.net *.split]
ChanServ has quit [*.net *.split]
elskwid has quit [*.net *.split]
xargoon has quit [*.net *.split]
onewheelskyward has quit [*.net *.split]
namelessjon has quit [*.net *.split]
indrek has quit [*.net *.split]
jfredett has quit [*.net *.split]
ryanf has quit [*.net *.split]
cored has quit [*.net *.split]
dbussink has quit [*.net *.split]
postmodern has joined #rom-rb
cored has joined #rom-rb
dkubb has joined #rom-rb
jfredett has joined #rom-rb
indrek has joined #rom-rb
Gibheer has joined #rom-rb
ryanf has joined #rom-rb
shingara has joined #rom-rb
kpwz has joined #rom-rb
xybre has joined #rom-rb
kalleth has joined #rom-rb
jdsiegel has joined #rom-rb
dbussink has joined #rom-rb
elskwid has joined #rom-rb
onewheelskyward has joined #rom-rb
namelessjon has joined #rom-rb
kapowaz has joined #rom-rb
xargoon has joined #rom-rb
solnic has joined #rom-rb
ChanServ has joined #rom-rb
mbj has joined #rom-rb
theCrab has joined #rom-rb
<theCrab>
am setting up my lib on the home machine
<theCrab>
installing devetools
<theCrab>
i have not installed ruby 2.0 at all and rvm/bundle complains ===> `ruby_20` is not a valid platform
<mbj>
theCrab: Install a more recent bundler.
<theCrab>
mbj: how do i invoke inflect ? so i can do birthday {20.years.ago}
<theCrab>
mbj: install has worked now. awesome
solnic has quit [Quit: Leaving...]
<theCrab>
I must be doing something wrong because i am not getting any complains from devtools (0)
mbj has quit [Read error: Connection reset by peer]
jfredett has quit [Quit: Leaving.]
<cored>
getting this error with devtools bin/devtools:8:in `require': cannot load such file -- devtools (LoadError)
<cored>
I clone the repo and did gem build after that installed devtools and then devtools init
mbj has joined #rom-rb
mbj has quit [Client Quit]
cored has quit [Ping timeout: 256 seconds]
cobbr2 has joined #rom-rb
cobbr2 has quit [Quit: Leaving.]
cobbr2 has joined #rom-rb
mbj has joined #rom-rb
cobbr2 has joined #rom-rb
<snusnu>
yo mbj
<mbj>
snusnu: hola
<snusnu>
mbj: i have a question re the bug you recently found with substation, when there was an exception in the failure chain
<snusnu>
mbj: so the thing is, currently, when an exception is raised inside a failure chain, the exception chain of that failure chain gets invoked, not the exception chain of the "original" chain
<snusnu>
mbj: it still suffers from the same bug you saw, but yeah, i was wondering if that's the most straightforward thing to do
<snusnu>
mbj: at least it means that all the failure chains need an exception chain configured too
<snusnu>
mbj: most probably you'd want to use the same exception chain for *all* chains anyway
<snusnu>
mbj: so i'm wondering, if anything should be changed (in addition to fix the initial bug)
<mbj>
This looks like "failure failure handling"
<snusnu>
exactly
<mbj>
Sure we wanna do this?
<snusnu>
no
<snusnu>
but it's not exactly that
<snusnu>
it's not like we're trying to handle exceptions in exception chains, which would be more closely what you said i guess
<snusnu>
it's more about standardizing behavior in case of an unhandled exception
<snusnu>
it somehow seems to me, that all exception should be treated equal …
<snusnu>
well, not really, but in the context of substation
<mbj>
TBH, no idea currently
<snusnu>
so, it feels like a bit of overhead, having to pass the same exception chain also on failure chain construction
<snusnu>
it may be ok for now tho, but it's something to remember
<snusnu>
we could also make it so that failure chains inside a chain, get the same exception chain the original chain uses