Greg London wrote: [...Lots of fascinating stuff removed...] > > It's not a language problem. It's not a construct problem. > It's not that embedded folks don't know that exceptions > are nothing more than jumps.
And yet they do use jumps, no? > When it comes down to it, it's a *system* issue. > > When all the pieces come together, and they are designed > from the ground up to "do this, and if an interrupt happens > stop and do that", then how do you guarantee a 30 hz refresh > rate? Well, interrupts aren't exceptions. But one could say the same with any 'if' test & a jump, no? Isn't the answer is that you ensure all code paths finish in time? [...] > Embedded engineers have to use constructs that can guarantee > refresh rate. THey have to design teh system so that there > are no exceptions, because they can't guarantee how long any > particular exception will take, or how many exceptions they > might get at any particular time. Well, you get one exception at a time, much like you get one if or goto or return at a time. No different than jumps. This again seems like you're talking about interrupts. That's a whole different issue. If you don't want interrupts, then you don't want interrupts, regardless of them subsequently triggering exceptions, gotos or anything else. Of course, when you are in code that does not have stack frames, then (arguably? not arguably?) you can't have anything that would reasonably be called an exception -- it's just a goto/jump. So it's a bit moot. But if you have a call stack, and you want code to execute "quickly" in order to meet a time constraint (hard or not), then the idea is to use exceptions-as-goto to avoid testing return codes (perhaps redundantly). A classic (but loaded) topical example is reading a file (or whatever) until EOF. EOF is not an error -- it could never seriously be argued that it's an error for files to have an end. If you're using a random-access API, then it's indeed probably "an error" to ask for data outside the file; but when you're using a stream-like API, then it's simply bound to happen that you say "next()" and get "EOF". Now, checking every next() call to see if it returns EOF (or sets some EOF flag variable) is inefficient, relative to having next() throw an exception -- essentially jumping directly to your code in the place that's supposed to run when the stream is emptied. _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
