Consider a continuous build server that makes a large project, then runs tests on the code. If one programmer makes a submission that causes a compile error in a method, this breaks the build and the tests never even start. However many tests may never execute the broken method. Assuming the programmer that broke the build isn't me (of course), I'd still like to see my own test results. It would also be nice to get a visual indication of which tests the compile error would affect in practice.
Jim 2008/10/24 Alexey Zinger <[EMAIL PROTECTED]>: > > I hope I'm not missing something crucial in this discussion, but what is the > benefit of running partially compiled code? If I introduce a compilation > error, why do I want to proceed with either an incomplete class set or one > class out-of-date, while another is new? > > Alexey > 2001 Honda CBR600F4i (CCS) > 1992 Kawasaki EX500 > http://azinger.blogspot.com > http://bsheet.sourceforge.net > http://wcollage.sourceforge.net > > > > --- On Fri, 10/24/08, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > >> From: Reinier Zwitserloot <[EMAIL PROTECTED]> >> Subject: [The Java Posse] Re: A lenient compiler? >> To: "The Java Posse" <[email protected]> >> Date: Friday, October 24, 2008, 9:39 AM >> Eclipse does this, even if you don't use the debugger. >> The method with >> the error in it is replaced with a simple exception, and >> the rest is >> compiled normally. When that method is called, it blows up, >> otherwise, >> it runs fine. >> >> There are two separate steps in creating a lenient >> compiler: >> >> 1. 'error recovering' parser: We're obviously >> not going to get far if >> the simplest of syntax errors makes the parser just stop. >> >> 2. a compiler that still produces a class file and knows to >> insert a >> dummy. >> >> >> #1 is by far the hardest thing to do, and we're in >> luck: javac is even >> better at recovery than ecj these days (particularly when >> you use a >> lot of anonymous classes; the ecj error recovery system >> just stops >> flat out when something goes wrong there), and the new >> langtools >> project is focussed on improving recovery even more. #2 is >> relatively >> easy, but as far as I can tell, javac doesn't currently >> do it. Hacking >> javac shouldn't even be that difficult, but, given that >> the hard work >> is already done, it would be great if the official javac >> just had a >> parameter (something like -Xdummy at first, possibly >> introduce it as a >> required feature for the 'jdk' stamp (no -X, just >> -dummy), later. It >> might be worth it to see what netbeans does; if it does >> produce dummy >> code, then just rip the javac back out of netbeans, and >> voila. >> >> >> On Oct 24, 1:39 pm, Christian Catchpole >> <[EMAIL PROTECTED]> >> wrote: >> > Or simply.. >> > >> > for (;;) { >> > System.out.println("Donkey."); >> > >> > } >> > >> > On Oct 24, 4:32 pm, Casper Bang >> <[EMAIL PROTECTED]> wrote: >> > >> > > > - at the failing code block, insert throw >> new >> > > > CodeMissingYouNoobRuntimeException(); >> > >> > > Nah, better to reuse >> java.nio.charset.CoderMalfunctionError ;) >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
