@Eregon You're right, my bad, I happened to be on a project which still runs on Ruby 3.1. However, the colon is present on Ruby 4.0 as well: ``` path/to/test.rb:1:in 'Integer#/': divided by 0 (ZeroDivisionError) from path/to...svoop (Sven Schwyn)
The `#backtrace` of exceptions are currently printed like so: ``` /path/to/whatever.rb:8:in `/' /path/to/whatever.rb:8:in `show' (...) ``` Most terminals recognize `/path/to/whatever.rb:8` as a local file and make it clickable ...svoop (Sven Schwyn)
@jeremyevans0 Nice one, thanks for the hint! I'll add this to a `ProviderError` and inherit from there. I guess this use case is too specific to add this `self.&` to `StandardError` or even `Exception` upstream? svoop (Sven Schwyn)
The introduction of `Exception#cause` helps a lot when debugging nested errors. Same goes for wrapped errors. I'm not really sure whether such wrapped errors are an advisable pattern to begin with, feel free to comment on this, but I'...svoop (Sven Schwyn)
@byroot You're right of course, I'm so tuned in to keyword arguments. :-) Can be done in Ruby as `def respond_to?(*args)`, but you'd have to check the last args member for type. It might be more ore less ugly in C, I honestly know zilch ...svoop (Sven Schwyn)
@byroot You're right, breaking backward compatibility of the signature is out of the question. Not sure for C, but in plain Ruby, it's not a problem: ```ruby def just_checkin(*methods, include_all: false) puts methods.inspect, inc...svoop (Sven Schwyn)
Fair point, but I don't think `respond_to_any?` is a real use case given `respond_to?` is mostly used to check whether an object implements the necessary interface: The information "it implements method1 OR method2" has little practical ...svoop (Sven Schwyn)
Not sure whether this is a good idea at all, but I guess it doesn't hurt to put it up for debate. The preferred way to check e.g. whether an argument is acceptable is by use of `respond_to?`: ```ruby # Don't def notify(recipien...svoop (Sven Schwyn)
svoop (Sven Schwyn)06:57 PM Ruby Feature #21960: Improve #backtrace to not confuse terminals