Re: fhpd vs RuntimeExceptions

[Mark Wielaard <mark at klomp dot org>]

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