URI::parse(nil) #=> nil about addressable HOT 4 CLOSED

OK everyone, we're going to take a poll on this one. This would be a huge breaking change. I've got tons of code that relies on this behavior, and while you obviously disagree, I strongly prefer the current behavior. Basically, unless the whole community jumps on this issue and tells me I'm wrong (very possible, I'm often wrong), then this issue will be closed. Also, if anybody prefers the current behavior, it's probably worth mentioning it or we'll have crazy selection bias. :-P

from addressable.

I'm just at a loss to understand it. It looks like a special-case ::new - so it makes sense to return an object of class Addressable::URI or fail.

The fix for broken code is easy: URI::parse(var) rescue nil

The benefit is that if var happens to be nil, you have powerful flow control built in, as well as strong error conditions at the site of misuse.

from addressable.

Also, Addressable is described as a replacement for std-lib URI.

URI(nil) #=> raise URI::InvalidURIError: bad URI

from addressable.

Addressable is not a perfect drop-in replacement. It usually works as one, but there are plenty of edge cases where it won't work as such. This is a feature, not a bug, because the standard library is downright wrong on its handling of quite a few things.

Haven't seen anyone else jumping in on this issue, and since this is the first time it's come up, I'm going to go ahead and close this.

If someone had raised this issue two years ago, I might've made the change, but I'm not going to consider it right now. Maybe when Addressable hits 3.x.

from addressable.