Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #34660
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Could not find or load main class com.mindprod.ensure.Ensure |
| Date | 2016-06-16 11:01 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <nju0tn$r05$1@dont-email.me> (permalink) |
| References | (4 earlier) <njnoa4$17j3$1@gioia.aioe.org> <fc19649e-4f2f-4925-8b3c-fdccab0badc1@googlegroups.com> <njq50f$530$1@dont-email.me> <njsumd$r9r$1@dont-email.me> <njt11p$b2f$1@dont-email.me> |
On Wed, 15 Jun 2016 21:56:58 -0400, Eric Sosman wrote: > (Hint: Where is the stack trace you *would* have seen had the GODDAM > STOOPID MISBEGOTTEN IMBECILIC[*] try/catch not bit-bucketed it?) > > [*] (Off my medications, will resume them when/if I get rational.) > I don't find a stack dump as useful as the output from a diagnostic/ tracing system I wrote that gets included in most of my code and left there after development is finished. Its controllable for the amount of tracing detail it outputs and has the ability to capture a configurable number of trace messages in a circular buffer and dump them when an error is reported. You can blame my exposure to both the Algol68R compiler and runtime system for the tracing style and ICL's George 3 OS for the circular buffers: - if an Algol68R program crashed it produced the most marvellous diagnostic report. This showed all currently active variables and their contents together with the run history showing not only the procedure call stack but the execution path taken through them, something like: PROC myproc(arg="cat") called int n = 23 Line 4 - if.. else Line 12 - if..then Line 34 For executed 8 times .... - When George 3 came unstuck it dumped two circular buffers, one showing the last 100 code modules executed and the other showing the last 100 checkpoints in those modules. Both systems made problem diagnosis very simple. Combining them allows me to use fairly detailed tracing when bug hunting in a long-running program without getting buried in megabytes of trace log: setting the buffer size to 100-200 trace points is usually enough to show where a program crashed and what earlier event caused the crash. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread
Could not find or load main class com.mindprod.ensure.Ensure Roedy Green <inquiry@mindprod.com> - 2016-06-13 06:51 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Roedy Green <inquiry@mindprod.com> - 2016-06-13 07:02 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Douglas <e.d.programmer@gmail.com> - 2016-06-13 07:15 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Roedy Green <inquiry@mindprod.com> - 2016-06-13 07:35 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Lew <lewbloch@gmail.com> - 2016-06-13 13:48 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Roedy Green <inquiry@mindprod.com> - 2016-06-13 14:11 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-13 20:54 -0400
Re: Could not find or load main class com.mindprod.ensure.Ensure Arne Vajhøj <arne@vajhoej.dk> - 2016-06-13 21:57 -0400
Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-13 22:58 -0400
Re: Could not find or load main class com.mindprod.ensure.Ensure Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-14 10:33 +0000
Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Douglas <e.d.programmer@gmail.com> - 2016-06-14 04:59 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-14 15:11 +0000
Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-14 11:31 -0400
Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Douglas <e.d.programmer@gmail.com> - 2016-06-14 09:00 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-14 13:18 -0400
Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Douglas <e.d.programmer@gmail.com> - 2016-06-14 10:38 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Lew <lewbloch@gmail.com> - 2016-06-14 12:55 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Douglas <e.d.programmer@gmail.com> - 2016-06-14 13:14 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Lew <lewbloch@gmail.com> - 2016-06-14 13:34 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Douglas <e.d.programmer@gmail.com> - 2016-06-14 13:58 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Lew <lewbloch@gmail.com> - 2016-06-14 12:52 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Stanimir Stamenkov <s7an10@netscape.net> - 2016-06-15 02:46 +0300
Re: Could not find or load main class com.mindprod.ensure.Ensure Lew <lewbloch@gmail.com> - 2016-06-15 12:22 -0700
Re: Could not find or load main class com.mindprod.ensure.Ensure Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-16 01:17 +0000
Re: Could not find or load main class com.mindprod.ensure.Ensure Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-15 21:56 -0400
Re: Could not find or load main class com.mindprod.ensure.Ensure Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-16 11:01 +0000
csiph-web