Open Side Menu Go to the Top

04-07-2016 , 11:59 PM
Quote:
Originally Posted by Grue
eh? Is it that hard to render it to the dom with display none on it then immediately do whatever transition? There's even an exact method for what you'll need, componentDidMount. or just bake it into the rendor directly by adding a class to fade or slide it in.
like i said, you can work around it, but it's awkward.

the guiding principle of react is that the view is simply a rendering of the always up-to-date model. this simplicity is the entire point of react's design. it means reactive interfaces can be reduced to the mental model of a mail merge template.

but this breaks down in the case of transitions like a slide in new page effect. what is the model that is being rendered to the screen? instead of the state of the page, it is now "the state of the old page" + "the state of the new page" rendered side by side during a slide transition + an "onEnd" event that deletes the old page and makes the new page "the page" again so that we finally return to our simple mental model.

your choices then are to add complexity to your view model (the component state in react), so that it can model both pages and the various transition states, or else to keep the nice 1 page model and just cheat -- break outside of the react system for just the transition.

so the thing that you're blowing off is conceptually a big deal. it's also a pain to get right in practice, at least it was when i did it in mithril.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **
$25m Guaranteed WPM on CoinPoker
Join the action now
Daily Rewards • Splash Pots • CoinRaces
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **
04-08-2016 , 01:28 AM
suzzer, other Node experts:

Code:
events.js:154
      throw er; // Unhandled 'error' event
      ^
Error: connect ETIMEDOUT 23.96.96.142:443
    at Object.exports._errnoException (util.js:890:11)
    at exports._exceptionWithHostPort (util.js:913:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1061:14)
How tf am I supposed to debug this when it doesn't even tell me where in my code it came from?
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-08-2016 , 11:25 AM
If this is an express error you need to use an errorHandler, which has a special method signature of (err, req, res, next) in your normal app flow.

Code:
  // if we get an error, we send a 500
  if (app.config.dump_errors) 
    app.use(dumpErrors);
  else 
    app.use(cleanErrors);

  function dumpErrors(err, req, res, next) {
    if (err === 'isRedirect') {
      debug('redirecting - ' + req.path + ' -> ' + res._headers.location);
      return;
    }

    debug('dumpErrors - 500 - errMiddleware!!');
    
    var errStr = (err.stack) ? err.stack : err.toString();
    if (req.errLog) 
      req.errLog.error(debug(errStr));
    else 
      debug(errStr);
    res.status(500).send('<h1>500 Server Error</h1><h3><pre>' + errStr + '</pre></h3>');
  }

  function cleanErrors(err, req, res, next) {
    
  // does error handling in production where we don't want to show the error to the end user
Try something like that, see if it gives you more useful error handling. I believe express should catch any lower level errors and bubble them up to you. Btw to throw errors yourself call next(error) where error is a string or error object (and the string isn't 'route').

Now if this doesn't work you may need to add something like the file below to catch lower level errors. Our hotshot node consultant set us up with this years ago and I've rarely had to touch it.

In app.js:
Code:
var lifecycle = require('./lifecycle');

     lifecycle
        .restart(config.restart)
        .bail(config.bail)

    lifecycle.on('bail', function(err) { app.log.error('lifecycle bail: ' + (err.stack || err)); });
I don't think we really use the restart stuff because we have nodemon on our dev machines and supervisor in the test/prod environments. But the bail is useful to catch and log low level errors (before either nodemon or supervisor restarts node).

Lifecycle.js
(bailOnError is the one you'll be most interested in):
Code:
var util = require('util');
var events = require('events');
var cluster = require('cluster');
var os = require('os');
var debug = requireFromRoot('lib/framework/debug')('lifecycle');

// Lifecycle
function Lifecycle() {
  this._main = undefined;
  this._restart = true;
  this._bail = true;
  this._workers = os.cpus().length;
  this._config = {};
}

// HBL: Idiomatic node.js inheritance
// In general though, composition works better than inheritance, and is easier to understand later.
util.inherits(Lifecycle, events.EventEmitter);

Lifecycle.prototype.bail = accessor('_bail');
Lifecycle.prototype.restart = accessor('_restart');
Lifecycle.prototype.workers = accessor('_workers');

Lifecycle.prototype.start = function(startFn) {
  this._main = startFn;
  if (this._bail) this._bailOnError();
  this._balanceCluster();
};


Lifecycle.prototype._bailOnError = function(fn) {
  process.on('uncaughtException', onException);

  var me = this;
  function onException(err) {
    var exit = fn ? fn(err) : true;
    me.emit('bail', err);

    console.error('lifecycle bail:', err.stack || err);
    debug('lifecycle bail: ' + (err.stack || err));

    if (exit) process.exit();
  }
};

Lifecycle.prototype._balanceCluster = function() {
  var self = this;

  return cluster.isMaster? startMaster() : startWorker();

  function startMaster() {
    var workerCount = self._workers;

    if (self._restart) {
      cluster.on('exit', onWorkerExit);
      cluster.on('death', onWorkerDeath);
    }

    while(workerCount--) cluster.fork();
  }

  function startWorker() {
    self._main(/*_.clone(self._config)*/);
  }

  function onWorkerExit(worker) {
    console.log('lifecycle:balance - worker exit, forking replacement');
    debug('lifecycle:balance - worker exit, forking replacement');
    cluster.fork();
  }

  function onWorkerDeath(worker) {
    console.error('lifecycle:balance - worker death, forking replacement');
    debug('lifecycle:balance - worker death, forking replacement');
    cluster.fork();
  }
};

// Exports
module.exports = new Lifecycle();

// Utils
function accessor(key) {
  return function(val) {
    if (arguments.length === 0) return this[key];
    this[key] = val;
    return this;
  };
}
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-08-2016 , 04:18 PM
Thanks, I'll try that, I am using Express. I only get these random crashes like once every 48 hours or so right now so it takes awhile to figure out if any fixes I apply have worked
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-08-2016 , 07:13 PM
Also it just occurred to me that the information you showed may be all you get. Basically you have a connection timeout somewhere. What is node connecting to on the back end.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-08-2016 , 07:17 PM
If you're only getting crashes once every 48 hours you can just use something like this, https://github.com/foreverjs/forever to auto restart when it crashes.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-08-2016 , 09:59 PM
we use these guys

https://keymetrics.io/

to monitor node. lots of cool features including helping you figure out bottlenecks in your code.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 07:01 PM
Quote:
Originally Posted by suzzer99
Also it just occurred to me that the information you showed may be all you get. Basically you have a connection timeout somewhere. What is node connecting to on the back end.
Yeah, that was the full callstack given to me by Node, I wish it had more of a hint as to where the timed-out request came from!

It occurred to me also that it probably isn't likely to be Express - there's not anything too exciting happening on the backend, Express is just serving up HTML/JS/CSS files. I have a Mongo database which is running on the same host (this is all on OpenShift, coworker recommended it), so the most likely candidate seems to be the HTTP requests I'm making to PredictIt.

One thing occurred to me - I'm not handling the 'error' event that the web response object can emit, would not having an error handler cause the web response to throw an exception? Like, this is what I'm doing:

Code:
  var request = https.request(options, function (res) {

    res.on('data', function (d) {
      ...accumulate data
    });
    res.on('end', function () {
      ...parse, catch parsing errors
    });
  });
  request.end();
Dunno if I need a request.on('error') or a res.on('error'). I looked up and down the Node documentation (what a mess) but couldn't find anything saying that failing to add an error handler for those (not even sure from documentation if the request object emits an 'error') would result in it being thrown as an exception. A couple google searches hinted that might be the case, though.

Quote:
Originally Posted by fruit snacks
If you're only getting crashes once every 48 hours you can just use something like this, https://github.com/foreverjs/forever to auto restart when it crashes.
Thanks - currently I kinda like that it crashes so I at least know something went wrong, but that could be a good option in the future.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 07:13 PM
For other C++ guys, curious what you think about this.

At work, on our large C++ project, a common pattern for objects that contain other class objects - let's say, Foo - is to:
- in header file, forward declare Foo and add a Foo* member to the class
- in source file:
- - include the header that defines Foo
- - initialize the Foo* member with "new Foo(...)"
- - delete the Foo* member in the destructor

I kinda hate this, since it adds the possibility of leaking memory and the nature of pointers means you can't, without more information, know for sure that it can't be null, even though in practice these pointers are never null.

My coworkers' argument in favor of doing it this way is that by forward declaring Foo in the header instead of including the file that defines Foo, it reduces compile times. Do any of you guys know (if you've been in situations like this before) how compelling of an argument that is, and how much of compile times is the result of header parsing?

If you did do things this way, would you prefer that the member field be a std::unique_ptr<Foo> instead of a Foo*?
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 08:01 PM
I don't really have a strong opinion about it, but your concerns don't seem too serious to me. Using unique_ptr seems fine, and that should take care of your memory leakage concerns.

I think worrying about NULLs is equivalent to worrying that a (non-pointer) class member was not initialized in the constructor. I mean, yeah, it's possible to **** up and not do either of these, but that's kinda just life.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 08:04 PM
Quote:
Originally Posted by RustyBrooks
I think worrying about NULLs is equivalent to worrying that a (non-pointer) class member was not initialized in the constructor. I mean, yeah, it's possible to **** up and not do either of these, but that's kinda just life.
Another coworker introduced a bug of that nature just last week!!

The longer I've been doing this, the more I've developed a mentality of "minimize the ways you can potentially **** up, because you will **** up".
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 08:11 PM
You're also fragmenting object memory and introducing additional cache misses all over the place if it's a performance-critical project.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 08:27 PM
Quote:
Originally Posted by PoppaTMan
You're also fragmenting object memory and introducing additional cache misses all over the place if it's a performance-critical project.
If you use just "new" for all the object pointers, yeah. There are abatement strategies, such as using "placement new" which will allocate a new object on an existing piece of memory. You sort of just have to choose what you value most (in this case, compile time/memory efficiency/complexity)

My point re: not initializing objects is, even if they don't use a pointer to the class, they have essentially the same chance of not initializing the pointer as they would not initializing the member. It doesn't increase the error surface.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 08:44 PM
Actually, I may not have understood what you meant - I thought you were suggesting the general category of null errors is like the general category of not initializing things in constructors, and what my coworker did was add an int member or something to a class without initializing it in the constructor.

If you're talking specifically about this hypothetical Foo example, I don't think I get it - member objects have to be initialized in the constructor.

I don't think that failing to initialize the member pointer is a likely problem, my annoyance with the pointer is more just that it's annoying to have a nullable type (in this case, a pointer) representing something that will never be null in practice.

edit: This discussion just gave me the idea of writing a variant of unique_ptr that doesn't allow for the possibility of being null (like, construction of the smart pointer = constructing the underlying object, removing the nullable issue from the equation).

Last edited by goofyballer; 04-09-2016 at 08:56 PM.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 08:56 PM
Quote:
Originally Posted by goofyballer
If you're talking specifically about this hypothetical Foo example, I don't think I get it - member objects have to be initialized in the constructor.
Well, not really? I mean, they will be initialized to SOME value, but if you leave out the initialization step (like say you wanted to initialize it as Foo(1, 100)) and it initializes using the default constructor, sure, you have "a value" but it's usefulness probably isn't gonna be a lot better than a null pointer.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 09:02 PM
If default initialization for Foo isn't cool, then Foo probably shouldn't have a default constructor.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 09:19 PM
I pity the Foo.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 09:23 PM
Quote:
Originally Posted by goofyballer
If default initialization for Foo isn't cool, then Foo probably shouldn't have a default constructor.
OK, you just kicked the can one step further upstream. Now you have a different "rule" about classes that can't be enforced in the language spec. Thou shalt not make classes with default constructors. In the end you're going to have to be comfortable with the fact that there are things that your infrastructure requires you do to, that you can't actually be forced to do.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 09:26 PM
(BTW, you sort of came up with your own solution, if you can make them do it, which is to use a special Pointer class, that doesn't have a default constructor. Now they'll be required to initialize the pointer. This doesn't stop someone from setting it to NULL though, and of course, it doesn't stop them from not using your nice Pointer class)
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 10:03 PM
Quote:
Originally Posted by RustyBrooks
Now you have a different "rule" about classes that can't be enforced in the language spec. Thou shalt not make classes with default constructors.
?

I mean, I don't know if this is a warning-as-error sort of thing in our build setup or if the language enforces it (I think the language does, perhaps that's new in C++11?), but if Foo doesn't have a default constructor, and I don't initialize Foo in the constructor of a class that contains a Foo, my program doesn't compile.

It's fine for Foo to have a default constructor, but if it does then it should probably initialize the object to such a state where it can't be described as "probably not much more useful than a null pointer", as you put it.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 10:15 PM
Quote:
Originally Posted by goofyballer
Yeah, that was the full callstack given to me by Node, I wish it had more of a hint as to where the timed-out request came from!

It occurred to me also that it probably isn't likely to be Express - there's not anything too exciting happening on the backend, Express is just serving up HTML/JS/CSS files. I have a Mongo database which is running on the same host (this is all on OpenShift, coworker recommended it), so the most likely candidate seems to be the HTTP requests I'm making to PredictIt.

One thing occurred to me - I'm not handling the 'error' event that the web response object can emit, would not having an error handler cause the web response to throw an exception? Like, this is what I'm doing:

Code:
  var request = https.request(options, function (res) {

    res.on('data', function (d) {
      ...accumulate data
    });
    res.on('end', function () {
      ...parse, catch parsing errors
    });
  });
  request.end();
Dunno if I need a request.on('error') or a res.on('error'). I looked up and down the Node documentation (what a mess) but couldn't find anything saying that failing to add an error handler for those (not even sure from documentation if the request object emits an 'error') would result in it being thrown as an exception. A couple google searches hinted that might be the case, though.
Yeah if you're gonna use the low-level https module, you need to add req.on('error')... https://nodejs.org/api/https.html#ht...tions_callback

Code:
var req = https.request(options, (res) => {
  console.log('statusCode: ', res.statusCode);
  console.log('headers: ', res.headers);

  res.on('data', (d) => {
    process.stdout.write(d);
  });
});
req.end();

req.on('error', (e) => {
  console.error(e);
});
I would recommend using superagent instead. It's much more user friendly.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 10:17 PM
If you forget to initialize an object by calling it's constructor with the parameters you want, then it'll be initialized to a state that doesn't represent what you want. This is as much of a problem as a null pointer, imo, because sure, it might not immediately crash, but it'll produce incorrect results.

When I say you've kicked the can up to the next level, I mean, now you have to tell everyone "don't make default constructors, because otherwise you might add a member to a class without initializing it". This is about as likely to succeed overall as telling them "don't forget to always initialize class members"

Not to mention, a significant percentage of the classes you deal with on a daily basis you probably won't even have the source code to, and many of those will have default constructors. And your coworkers will probably get mad if you start taking away their default constructors because that doesn't jibe well with whatever class you're working on.

I'm mostly playing devils advocate at this point, because I honestly don't think any of these represents much of a problem, but basically, if you're concerned about a class member not being initialized via oversight, you're equally ****ed if
* it's a non pointer member and someone forgot to initialize it
* it's a pointer to another class and someone forgot to set the pointer
I think each is about equally likely to be made as a mistake, has similar types and severities of problems, and has about the same level of remedy available.

For example, you could as I said make the Pointer class, which would ensure that no one forgot to set the pointer, as long as they used your Pointer class. You could also use this class to automate the destruction of the object, as in unique_ptr, and you could also probably even facilitate using placement new to avoid the memory problems mentioned above.

Does that seem worth it to me? No. I don't use this silly trick as you described. If it really bugs you and you have any say in the matter, make them prove to you that it really does speed up compilation time. We had a saying at my last job: "don't boil water in the microwave"

It's kind of a silly story, but one of our founders came up on a guy boiling a mug of water in the microwave. He says "why you doing that?". Guy says "it's faster." Founder is like 'lol no' and they have a timing contest between the microwave and the kettle, the kettle wins handily.

Which is to say, it's not a (whole lot) faster just because your coworkers say it is. Maybe it is, maybe it isn't, I dunno. I agree that it adds an extra level of fluffery that does you no real good - *unless* it compiles way faster, and that's of actual importance.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 10:33 PM
Quote:
Originally Posted by RustyBrooks
If you forget to initialize an object by calling it's constructor with the parameters you want, then it'll be initialized to a state that doesn't represent what you want. This is as much of a problem as a null pointer, imo, because sure, it might not immediately crash, but it'll produce incorrect results.

When I say you've kicked the can up to the next level, I mean, now you have to tell everyone "don't make default constructors, because otherwise you might add a member to a class without initializing it". This is about as likely to succeed overall as telling them "don't forget to always initialize class members"
I still feel like I'm only 30% sure I know what you're trying to say here. Are you saying that, in the instance where Foo has both a default constructor and a constructor that takes parameters, it's possible to put a Foo inside another class (say, Bar) and forget to initialize your Foo in Bar's constructor, leading to its default constructor being called?

Or are you saying the problem expands to more situations than this very specific one I've laid out? If so, please elaborate.

(I would still maintain that the Foo you have in that example is significantly more useful than an uninitialized pointer, even if it is not in the state you wanted)
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 10:41 PM
Quote:
Originally Posted by goofyballer
I still feel like I'm only 30% sure I know what you're trying to say here. Are you saying that, in the instance where Foo has both a default constructor and a constructor that takes parameters, it's possible to put a Foo inside another class (say, Bar) and forget to initialize your Foo in Bar's constructor, leading to its default constructor being called?
Yes, this absolutely happens. (although much more likely you might have 1 constructor that has default arguments)

Quote:
(I would still maintain that the Foo you have in that example is significantly more useful than an uninitialized pointer, even if it is not in the state you wanted)
Consider something like a class that opens a file and interacts with it. It's default constructor doesn't take a filename, or it permits you to use a default filename (could be a specific default file, an empty string, etc)

You forget to initialize it with a filename that is passed to the constructor of your outer class. How happy are you going to be with the result of
myFile.delete() or myFile.open()? These are either going to crash, throw an exception, or do something unexpected.
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
04-09-2016 , 11:13 PM
Okay, so now that I know what you're talking about, hopefully I can pull us out of the very deep weeds we're in back to where we started:

Quote:
Originally Posted by RustyBrooks
My point re: not initializing objects is, even if they don't use a pointer to the class, they have essentially the same chance of not initializing the pointer as they would not initializing the member. It doesn't increase the error surface.
All pointers can cause these errors; only classes with overloaded (or default-parametered) constructors could cause the issue you describe. Nearly all attempts to use a null or uninitialized pointer will crash your program; calling the wrong constructor (or forgetting to initialize with optional parameters on the default constructor) will crash your program or cause a massive failure only some of the time.

This particular class of errors was never a focus for me in starting this debate, though. When I mentioned the 'null' thing originally, I meant more like: if variable 'x' is a pointer type, then it could (by definition) be null, and that sometimes results in cluttering up code with spurious null checks (maybe not in the original file, but one or two degrees away when it's been passed somewhere - and this isn't a theory, people do this in our C++ code all the time) on pointers that are never, ever going to be null at runtime.

I did think of one other issue, going back to the reasons why the pointer thing bothers me:

Quote:
Originally Posted by goofyballer
I kinda hate this, since it adds the possibility of leaking memory and the nature of pointers means you can't, without more information, know for sure that it can't be null, even though in practice these pointers are never null.
Requiring a custom destructor to delete the pointers you allocated =
- no default move operations for your class
- default copy behavior will still be generated but is totally wrong
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD ** Quote
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **
$25m Guaranteed WPM on CoinPoker
Join the action now
Daily Rewards • Splash Pots • CoinRaces
** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

      
m