There are three basic patterns for a function to deliver errors. Throw delivers an error synchronously — that is, in the same context where the function was called. If the caller used try/catch, then they can catch the error. If none of the callers did, the program usually crashes. Callbacks are the most basic way of delivering an error asynchronously. The user passes you a function (the callback), and you invoke it sometime later when the asynchronous operation completes. The usual pattern is that the callback is invoked as callback(err, result), where only one of err and result is non-null, depending on whether the operation succeeded or failed. Promise rejections are a common way to deliver an error asynchrously. This method is growing in popularity since the release of Node.js version 8 that includes support for async/await. This allows asynchrounous code to be written to look like synchronous code and to catch errors using try/catch. 3.For more complicated cases, instead of using a callback, the function itself can return an EventEmitter object, and the caller would be expected to listen for error events on the emitter. Please have a Look into this article : https://www.joyent.com/node-js/production/design/errors Thank You.

1.The real problem, is that with HTTPS you lose the ability to cache. 2.small performance hit when using HTTPS, since "the SSL initial key exchange adds to the latency." 3.For sites that don't have any reason to encrypt anything—in other words, you never log in, so there's nothing to protect—the overhead and loss of caching that comes with HTTPS just doesn't make sense. However, for big sites like Facebook, Google Apps, or Twitter, many users might be willing to take the slight performance hit in exchange for a more secure connection. And the fact that more and more websites are adding support of HTTPS shows that users do value security over speed, so long as the speed difference is minimal.Although servers are faster and implementations of SSL more optimized, it still costs more than doing plain http 4.Perhaps the main reason most of us are not using HTTPS to serve our websites is simply that it doesn't work with virtual hosts. Virtual hosts, which are what the most common cheap Web hosting providers offer, allow the Web host to serve multiple websites from the same physical server—hundreds of websites all with the same IP address. That works just fine with regular HTTP connections, but it doesn't work at all with HTTPS. There is a way to make virtual hosting and HTTPS work together—the TLS Extensions protocol—but it's only partially implemented. Of course that's not an issue for big sites, which often have entire server farms behind them. But until that spec—or something similar—is widely used, HTTPS isn't going to work for small, virtually hosted websites. 5.There is no real reason the whole Web couldn't use HTTPS. There are practical reasons why it isn't happening today, but eventually the practical hurdles will fall away. Broadband speeds will improve, making caching less of a concern, and improved servers will be further optimized for secure connections.

I provided this link for static file : root /home/uday/NetBeansProjects/FannieMae/dist; But assets not are not getting 404 Error.

where? can you explain?

My Nginx config file is : server{ listen 80 ; listen 443 ssl; ssl_certificate /etc/nginx/ssl/nginx.crt; ssl_certificate_key /etc/nginx/ssl/nginx.key; location / { proxy_pass "http://127.0.0.1:8080" ; } location /FannieMae/ { root /var/www/apps/FanniMae/dist; rewrite ^/FannieMae(.*) $1 break ; proxy_pass "https://127.0.0.1:8000" ; location ~ ^/(images/|img/|javascript/|js/|css/|stylesheets/|flash/|media/|static/|robots.txt|humans.txt|favicon.ico) { root /var/www/apps/FanniMae/dist; } }