On Monday 02 July 2007 10:05, Melchior FRANZ wrote: > Yeah. It's also not only the Traffic Manager. FlightGear is full > of exit()s, when there should really be one single exit() at most, > and that would be in bootstrap.cxx. When the project was started, > gcc wasn't what it is now. I think templates were barely supported, > and exceptions blew up the binary size a lot and might not have > worked that well. I guess all this excessive exit()ing in all parts > of FlightGear predates exception handling. (At least it predates > good taste. :-) But it's now really time to stop with this.
I did a quick review of exit's in the Airports/ AIModels/ and Traffic/ directories. It seems most of the ones not commented out yet, are there for internal consistency, placed there during the first pass of development. (i.e. "If I pass the wrong variable here, things will go wrong, but if I pass the right variable, there's no way thing can go wrong but let's set a trap for this anyway). All of those can be removed safely, but it might be even better style to throw an exception there, even though the exception could only be thrown in case of a serious memory corruption error. A second major class of exits is related to reading in the datafiles at startup. These can be triggered even in correctly written code whenever the datafiles are corrupted. Considering that this can happen only during program startup, the big question is, do we want to continue with program initialization. I'd say probably not. The normal circumstance for encountering a corrupt data file will be either in the case of a file system error (serious), or a user who has hand edited a file. In both cases, this seems a valid reason to halt program execution, with a nice error message pointing which file and possibly which line of code was causing the halt. Because this happens during program initialization, the chances of pissing off a user isn't that high. The most significant exception (no pun indented) :-) to this rule seems to be the one related to the routing algorithm. It seems like the new algorithm is pickier than my old one. It is uncovering some missing segments in the networks that were previously undiscovered (and this after about a few days to about a week's worth of testing for each network). I had clearly not expected this, or I would have taken a different cause of action. I agree that a more elegant solution is in place here. Maybe just commenting out the the exit might work (for the adventurous), as that might trigger the default fallback mechanism, but in this case I really need to check if continuing doesn't result in memory corruption. (Which, assuming that the networks were sufficiently tightened-up, was actually the reason why I left this exit in for the time being). > > > However, the flip side is that if we continue to "gracefully recover", > > its going to be a lot tougher to weed out the /root/ cause of any bug. > > An exit() or an exception doesn't really help here. It only pisses > the user off and makes fgfs look bad. I think most developers run fgfs > from the command line and pay attention to error messages. I do. I would > definitely not ignore a message from the traffic manager: > > Traffic Manager problem in src/Traffic/TrafficMgr.cxx, line 341: > routing problem in EHAM data -- no endpoint found I certainly appreciate that. I just hope that every developer is as eager to report these errors. That being the case, I have not problems with a graceful recover. I'm just, let's say, cautious about the actual number of reports I'm seeing. :-) Cheers, Durk ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
