Re: Core Exception Throwing and Handling

[Phil Muldoon <pmuldoon at redhat dot com>]

And here is my own reply.

Phil Muldoon wrote:
> I thought I'd start this conversation going. It's been an action item 
> for awhile.
>
> Right now the core throws a lot of RuntimeExceptions. As all java 
> programmers know, a method is not required to declare 
> RuntimeExceptions or any of its sub-classes  in a throws clause. This 
> makes exception handing on the method caller optional. It also does 
> not give a heads-up to the method caller that it can expect an 
> exception. With libraries and programs the size of frysk, there are 
> dozens of interfaces into the core. Also RuntimeExceptions are pretty 
> generic. They usually have a message and a trace and not much else.

These exceptions are unchecked. There are various arguments out there 
for checked and unchecked exceptions. I sit on the fence in this regard. 
It is true that only Java has ever implemented both checked and 
unchecked exceptions (through technically all exceptions in Java are 
checked, as Exception is checked) and subsequent languages after 
(Ruby/C#) have not. There is a lot to learn from that. However from a 
purely client point of view, the client still has to figure out:

1) Is the exception bad? Will data corruption possibly occur if I continue;
2) Ah oh well, could not get that information, but it is ok to move on.

The buck stops with the client implementing the core. With small 
low-setup utilities like ftrace it might be ok just to print out the 
stack trace and quit. It took 20 second to set it up, and very little 
loss. With a large scale monitoring ui, that can be running for hours, 
watching many 100s of processes for many observable events, it has to be 
more robust. 16 hours into a monitoring session we would not want to 
quit because some lookup failed. This leads me to think of four scenarios:

1) Do what we do now. Show the exception in a window, and ask if the 
user wants to continue or quit
2) Log the exception and continue
3) Have a high exception throwing threshold. Only "bad" exceptions are 
thrown.
4) Quit the UI, print the stacktrace, wait for bugzillas

From the examples above:

1) Puts the position on the user. And expects the user to know what to 
do when the programmers didn't. It also brings the event loop to a halt 
while the user decides.
2) Would be okay if errors were recoverable. Some are .. and some send 
the core off into the weeds. From that point on it is somewhat braindead
3) Seems a cop-out. Might work if there was intelligence in the core to 
"thrown an exception" or return null (function failed).
4) Angry (quite rightfully) users.

It's tempting to think of this as a core issue or a ui issue, but it is 
really much more complex than that.

Regards

Phil