Is using progress.lang.apperror for warnings a bad idea ?

Posted by cverbiest on 30-Dec-2013 04:26

I'd like to handle errors and warnings in a similar way.

Display them, check the stack trace, write to a log file etc.

In order not to duplicate all the code that can handle errors I'm considering to create error objects for warnings as well. I would create an error object and instead of throwing it pass it to an Error/Warning helper service.

This service would then display/log the object.

I'd like some kind of sanity check here. Would I be abusing error objects when I use them for warnings , perhaps even for information messages.

All Replies

Posted by Thomas Mercer-Hursh on 30-Dec-2013 09:27

Someone once suggested to me that the problem with using a language's error throwing mechanism was that it took one out of the flow of control.  This was acceptable when the condition was such that one couldn't proceed with the expected flow of control anyway, but questionable when it was possible to recover.  This seems like sound thinking to me.  If you can expect the issue and code to compensate for it, then use some other reporting mechanism like log-manager to record what has happened.

Posted by gus on 30-Dec-2013 13:34

some questions come to mind.

what is the difference between a warning and an error?

who are they for?

what are they supposed to do?

Posted by Mike Fechner on 30-Dec-2013 13:48

Warnings can typically be ignored.

Not typically compatible with the flow of errors where the transaction or at least the operation is already cancelled and rolled back.=

Posted by Matt Baker on 01-Jan-2014 09:38

Generating the stack for an object is relatively expensive if your code is performance sensitive, don't do it.  If it isn't sensitive to performance, then its probably fine.  Don't base your logging/status information directly on the exception itself .  It is too limited and it will be hard to distinguish between a single exception, vs a set of warnings you may want to give the user.  

Generally you should wrap the error object in your own code which can make that distinction explicitly.  You'll also be able to grow it later as needed.  You'll find you probably want to add more stuff to it later.  Eclipse has a fairly decent way to do this using IStatus which accepts a status object which can optionally wrap an exception.  This is used nearly everywhere in the framework from UI validation routines, to returns from background jobs.  You can view it here to get some ideas of what might be useful.

The interface:

and its implementation:

This thread is closed