From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16473 invoked by alias); 15 Nov 2007 17:42:04 -0000 Received: (qmail 16431 invoked by uid 22791); 15 Nov 2007 17:42:03 -0000 X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,TW_FH X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 Nov 2007 17:42:00 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1Isiiy-0004Ry-ER; Thu, 15 Nov 2007 18:41:57 +0100 Subject: Re: fhpd vs RuntimeExceptions From: Mark Wielaard To: Phil Muldoon Cc: frysk@sourceware.org In-Reply-To: <473C7B74.6090109@redhat.com> References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> <473C7B74.6090109@redhat.com> Content-Type: text/plain Date: Thu, 15 Nov 2007 17:42:00 -0000 Message-Id: <1195148516.3010.27.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 (2.12.1-3.fc8) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q4/txt/msg00135.txt.bz2 Hi Phil, On Thu, 2007-11-15 at 17:01 +0000, Phil Muldoon wrote: > As talked about on IRC over the corefile > message design, exceptions can and are used to carry warnings, messages > and so on. How do you differentiate between a warning and an error in > this case? By using different exception types, so a higher level can distinquish between a "recoverable" warning and a "unrecoverable" error. > Take this example. I manufactured this warning to happen, but all the > message is telling the user is that it cannot read at the peek() address > given. It's not an error, just a cannot do. But the huge ugly backtrace > that follows is not very useful. > > (fhpd) core /home/pmuldoon/core.12463 /bin/bash > Internal debugger error: peek() at address 6992f8 cannot be found in > metadata table. > java.lang.RuntimeException: peek() at address 6992f8 cannot be found in > metadata table. > at frysk.proc.dead.CorefileByteBuffer.peek(fhpd) > at inua.eio.ByteBuffer.peek(fhpd) > at inua.eio.ByteBuffer.peekFully(fhpd) > at inua.eio.ByteBuffer.peekLittle(fhpd) > at inua.eio.ByteBuffer.peekLittle(fhpd) > at inua.eio.ByteOrdered$2.peekULong(fhpd) > at inua.eio.ByteBuffer.getULong(fhpd) > at inua.eio.WordSized$3.getUWord(fhpd) > at inua.eio.ByteBuffer.getUWord(fhpd) > at frysk.proc.dead.LinuxProc.sendrecMaps(fhpd) > at frysk.proc.Proc.getMaps(fhpd) > at frysk.dwfl.DwflFactory.updateDwfl(fhpd) > at frysk.dwfl.DwflCache.getDwfl(fhpd) > at frysk.debuginfo.DebugInfoFrame.getScopes(fhpd) > at frysk.debuginfo.DebugInfoStackFactory.createVirtualStackTrace(fhpd) > at frysk.hpd.CoreCommand.interpret(fhpd) > at frysk.hpd.ParameterizedCommand.interpret(fhpd) > at frysk.hpd.MultiLevelCommand.interpret(fhpd) > at frysk.hpd.CLI.execCommand(fhpd) > at frysk.bindir.fhpd.main(fhpd) > > If this is the way forward, I'll have to gobble exceptions locally in > CoreCommand, and just deal with them locally. Yes, I think that is the way forward. Something terribly failed. And just passing the "address 6992f8 cannot be found in metadata table." message to the user is clearly not very helpful if the user just wanted to run a specific command. Only the command knows if this is something fatal or not and should catch it at the appropriate level and report what the exact action was that was attempted and which structure couldn't be created because of the error. Cheers, Mark