Since felix has the beginnings of really strong concurrency support, it might be interesting to look at how Erlang handles errors.
The core philosophy in Erlang is "let it crash", where work is divided into lots and lots of workers (modeling the application after the natural concurrency patterns inherent in the problem). We divide the system into "workers" and "supervisors", where a supervisor simply monitors the worker and takes action if it dies. A suitable action might be to just restart the worker with default values, unless it keeps crashing - then the supervisor crashes and lets the next supervisor take action, etc. Eventually, a top-level supervisor will simply terminate the application. This is a wonderful way to write robust complex systems. Erlang also has try ... catch and throw, and these are of course essential too, but they work more or less like the felix counterparts, and given the greater scheme of workers and supervisors, and using the very lightweight concurrency to partition the work, stack traces and local exception handlers do become a bit less important. BR, Ulf W > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Artem Gr > Sent: den 4 april 2007 09:34 > To: [email protected] > Subject: Re: [Felix-language] Where now? > > > > Well two points: I personally do not use debuggers, stack > traces, > or any other debugging aids .. I use print statements. > > Stack trace is just an improved print statements: print > statements which gets into the log on demand. In the > functional languages, due to heavy optimizations, instead of > a "stack" trace there might be just a "function call trace", > providing it omits simple loops. Or it might be a "print" > trace! Say, we have a size-limited queue (for every thread?), > that's get the print statements pushed to it (preferably with > file and line number attached!), then, if a error occurs, we > jump to the catch block and log the queue contents for > examination. No error - no crap in the logs. Error - and we > have the history of what happened. Given that some errors > occur once in a while (say, some months of work) that's a > very important difference from simple print statements. > > > Still other people like that stuff. Felix is in a better > position > than many other systems, in that we can > instrument the generated > code .. for example, to record > function entry/exit. > > That's great! > BTW, tail recursion should not be a problem with some support from the > language: tail-recursive call is a goto to the same function > and shouldn't be treated as a function entry/exit by the > stack tracing machinery... > > > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join > SourceForge.net's Techsay panel and you'll get the chance to > share your opinions on IT & business topics through brief > surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge &CID=DEVDEV > _______________________________________________ > Felix-language mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/felix-language > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
