ignore exceptions on Websocket dispatch parsing

[arBmind]

For me this kept crasching in the HTTP::parser.
This hack makes this module usable for me.

[e2]

I can't accept that patch - especially not the empty rescue.

Also, for handling an error like this, a test case is needed - so what data did you get that caused the error?

[arBmind]

My setup:

• windows host
• ubuntu 14.04 vm on virtualbox (vagrant)
• guard runs on a non-shared folder
• livereload port is forwarded to the host (next to the webserver)
• Chrome is used to access the webserver and the livereload

Experience:

• telnet to the livereload port works but closing the session, crashes the guard-livereload
• activating the livereload browser extension works, but after one or two changes the livereload crashes.

As I said it's a hack, but it allows me to use this reliably.

That parsing of user input may fail is not really an exception - it should be expected. At least not one that should crash the service.

There is no error handling code in this file, so I went the lazy route.
Feel free to adapt, what seems right. It may also solve some of the open issues. I have not checked.
I would be very happy to see a working solution.

[e2]

The most frustrating issues are when something doesn't work and there's no error. Especially for users who aren't savvy enough to debug web sockets, etc.

Any error handling would have to be covered by specs, so it's best to use a real-life scenario. This includes testing for error messages properly shown.

Also, It's better to catch specific exceptions instead of all exceptions - and given most livereload users are designers, it's fair to "reinterpret" exceptions to tell people what could be wrong and how to fix it.

So what is the exact input you're getting that's causing the failure? Why is such an error "normal"?

If I can't reproduce the problem, there's a high chance this will either be a back-and-forth between you and me, or, many users will get very frustrated by "reloading not working" and us having no output to find the cause.

At least paste the data causing the failure - adapt it to prevent it having sensitive info if needed.

[AlexWayfer]

So what is the exact input you're getting that's causing the failure? Why is such an error "normal"?

I've catched it and described in #179.

I agree that we should not just add an empty rescue, and we should write tests and behavior for this.

But the situation is terrible for me as developer for different devices.