parseUrl craps on a null url #44

Closed
rdbcci opened this Issue Jan 10, 2013 · 2 comments

Comments

2 participants
@rdbcci

rdbcci commented Jan 10, 2013

Probably needs to take null url and act gracefully. thanks, Bob

parser = feedparser.parseUrl(null);
FeedParser.parseUrl.url=null
TypeError: Cannot use 'in' operator to search for 'href' in null
at Function.FeedParser.parseUrl (C:\Users\Mike\node\feedparser\node_modules\feedparser\main.js:1218:21)
at repl:1:21
at REPLServer.self.eval (repl.js:109:21)
at rli.on.self.bufferedCmd (repl.js:258:20)
at REPLServer.self.eval (repl.js:116:5)
at Interface. (repl.js:248:12)
at Interface.EventEmitter.emit (events.js:96:17)
at Interface._onLine (readline.js:200:10)
at Interface._line (readline.js:518:8)
at Interface._ttyWrite (readline.js:736:14)

@rdbcci

This comment has been minimized.

Show comment Hide comment
@rdbcci

rdbcci Jan 10, 2013

i suggest something like this in the beginning of parseUrl:

if(!url){
var e = new Error();
e.message = 'FeedParser.parseUrl does not accept null or undefined urls';
process.nextTick(function() {
if ('function' === typeof options)
callback = options;
callback(e);
});
return;
}

rdbcci commented Jan 10, 2013

i suggest something like this in the beginning of parseUrl:

if(!url){
var e = new Error();
e.message = 'FeedParser.parseUrl does not accept null or undefined urls';
process.nextTick(function() {
if ('function' === typeof options)
callback = options;
callback(e);
});
return;
}

@rdbcci rdbcci closed this Jan 10, 2013

@rdbcci rdbcci reopened this Jan 10, 2013

@danmactough

This comment has been minimized.

Show comment Hide comment
@danmactough

danmactough Feb 18, 2013

Owner

I wanted to think about this -- because I agree that the parameter handling is deficient. I'll be addressing that. But I don't agree that the failure to provide a url to the function should do anything but cause an error to be thrown. I'm actually going to explicitly throw going forward.

Errors the library encounters should get handled gracefully and passed (or emitted), but incorrect usage should throw.

Holding this open until the parameter handling changes land.

Owner

danmactough commented Feb 18, 2013

I wanted to think about this -- because I agree that the parameter handling is deficient. I'll be addressing that. But I don't agree that the failure to provide a url to the function should do anything but cause an error to be thrown. I'm actually going to explicitly throw going forward.

Errors the library encounters should get handled gracefully and passed (or emitted), but incorrect usage should throw.

Holding this open until the parameter handling changes land.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment