Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Could not find or load main class com.mindprod.ensure.Ensure Date: Tue, 14 Jun 2016 15:11:17 -0000 (UTC) Organization: A noiseless patient Spider Lines: 48 Message-ID: References: <64htlb5ikduodj9qr700ob3tqbulribl5a@4ax.com> <58be2264-bf4a-4da1-a6b2-8501e9daf435@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 14 Jun 2016 15:11:17 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="10563"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Ff7LrlUP8Xs4aqDeImx8VZe9Su4YpNJM=" User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 3663720 git://git.gnome.org/pan2) Cancel-Lock: sha1:mP0TIalGmJ/sO+kGUoDeJM3tFEY= Xref: csiph.com comp.lang.java.programmer:34630 On Tue, 14 Jun 2016 04:59:20 -0700, Eric Douglas wrote: > We add an email to IT with a screenshot and full details of the error on > all our crash logs. > Yes, that's a nice approach. What I was really getting at is that using the syslog to record problems is great if your code is running on Linux. some UNIX flavour or a mainframe. The Linux/UNIX logging system is really flexible so you can even dedicate a log file series to each production system running on the host system and have it automatically mail the day's log messages to the relevant sysadmin or maintenance team. Macs should also be able to do this since they're essentially running BSD. However, if your code is running on a PC and you want to capture client problems rather than server issues, something like Eric suggests is about the best you can do. > It's mostly the end user you're worrying about crashing the programs, so > aside from notifying IT, it should catch all errors to display a user > friendly message, then restart or exit if necessary with as much cleanup > as possible. > I'd hope that code released to end-users couldn't be crashed by them, but I know what you mean: how you think users will use a set of screens and what they actually do with them can differ quite radically. That said, exactly what you end up doing can be influenced by your user's attitude to the system and their background. Example: way back when I designed BBC Radio 3's music planning system the users were enthusiastic about the system because they'd asked for it. The music planning department was largely staffed by musicologists with relevant degrees. The system ran on a mainframe. As a consequence, we also gave the music planners access to the screen we used to control tracing and debugging during development. If they hit a problem we'd talk it over on the phone and, if it couldn't be resolved on the spot, we'd ask them to turn on tracing, cause the problem again and then turn tracing off. We'd get the printout the next day and talk to the planners as soon as we'd decided what the problem was and decide how we'd resolve it. Result: everybody was happy and we had exactly what we needed to decide what needed to be done. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |