[SNMP4J] What about uncaught RuntimeExceptions?

[Fabian Nart]

Hi Frank,

 > "try { ... } catch (Exception e) { return null;}"

obviously, this would be a stupid thing to do! What about logging and 
rethrowing:

try { ... }
catch (RuntimeException e) { LOGGER.Log(e); throw e;}
catch (Error e) { LOGGER.Log(e); throw e;}

...just in case the Runnable is not programmed properly.

Indeed, I was experiencing some trouble with a NullPointerException 
whose StackTrace is empty. This looks to me like an OutOfMemoryError has 
been silently caught. Or maybe it slipped uncaught out of a 
Runnable.run(). I am not sure about the origins of my problem, I just 
looked around the snmp4j-code and this sticked into my eyes.

Regards, Fabian

> The ThreadPool should be implemented so that it does not
> throw any Runtime or other "unexpected" exception.
> If you want to avoid any such exceptions you should
> use a try-catch in the Runnable.run() method you put
> into the thread pool.
> 
> I do not like catching exceptions at places where
> I do not have an idea to handle them. One of these
> famous
> 
> "try { ... } catch (Exception e) { return null;}"
> 
> Nevertheless, I am open to add your suggestion
> (for example by rethrowing the exception). Have you
> observed such a runtime exception that was caused
> by SNMP4J?
> 
> Thanks,
> Frank
> 
> 
> Fabian Nart wrote:
>> Hi,
>>
>> wouldn't it be nice to wrap the ThreadPool.TaskManager's 
>> run-method-body with a piece of code like the following?
>>
>> try {
>>   // here comes the method body as it is until now
>> } catch(RuntimeException re) {
>>   // do some logging
>> }
>>
>> I think this way we can be sure that there is no RuntimeException that 
>> we never be aware of (Who knows where the UncaughtException() method 
>> of the ThreadGroup writes its output to...)