Closed mfikes closed 9 years ago
@mfikes overriding :caught
is definitely not the right thing to do, but also isn't possible via :merge-opts
. You probably should not install a custom :caught
unless you are nREPL middleware or something like it.
I'm not sure that #50 was something that needing fixing. Was there some workflow issue you were trying to address?
Still perhaps this means that we need something like special-fns
for exceptions for the cases where the REPL evaluation environment has unrecoverable error and this needs to be communicated regardless of context, normal usage, nREPL etc.
@swannodette Cool. Will probably just revert the last few Ambly changes. Or at least the custom :caught
impl.
Since -setup
does a lot of (network) I/O, there is a possibility of failure to properly complete REPL setup (even half-way trough). Was just looking to somehow add robustness in the form of rolling back to previous state if -setup
cannot complete.
Perhaps one idea to ponder is: Can derived REPLs indicate that -setup
failed? (Or is it even worth the complexity, given that this is dev tooling?)
@mfikes I think one problem is that rolling-back behavior should probably not be defined at this level of REPL tooling. Any decision might make would probably adversely affect nREPL integration for example. We may very well need something else, but let's wait and see.
@swannodette Waiting is cool. My initial stance was along the lines of strong exception safety wikipedia, but perhaps REPLs don't need it.
@mfikes I agree with that -setup
should probably fail but we need @tomjakubowski to commit to waiting for connects, by not failing on -setup
Weasel gets to keep going and allow clients to connect whenever they like.
With #50 the changes made broke exception-handling when using the REPL. For example
(ffirst 1)
doesn't result in a source-mapped stacktrace because custom:caught
handler is being used.Adding
:caught repl/repl-caught
to:merge-opts
doesn't fix things.