2008/11/7 dkmd_nielsen [email protected]:
My application has a common routine to format error messages:
def FLIO.display_error(clss,err)
ln = ‘-’*70
ln should be a frozen constant - this is much more efficient.
lbl = "#{clss}_#{sprintf('%04i',err[:num])}"
ln[(ln.length - lbl.length)/2,lbl.length] = (' Error: ' + lbl +
’ ')
puts ln,err[:msg],ln
I would print errors at least to $stderr and not $defout.
caller and raise the exception, as implemented above? For IDE
purposes, this would set the trace to the right area. Or should I
pass the exception to the routine and raise it there? This would be
one less line of code for every exception trap.
What are your recommendations, in general, or raising exceptions in an
application?
I am not sure whether the idiom is ideal. There are many different
approaches with regard to error management and exception handling,
but: the basic idea of exceptions is that there is a place in code
that raises the error and there is another place (or multiple places)
in code that decides how to deal with that error. Your pattern breaks
this. An Example:
Module A has a method that does something which can fall victim to
exceptional circumstances and consequently raises an exception.
Module B has a method that uses A’s method but since there is an
alternative implementation in module C it catches A’s exception,
invokes C’s method and can complete fine.
(If you need a more concrete example think of data stored in a
database and as a backup in a file. DB access is fast so A does DB
retrieval. If that fails, B can still resort to the slow file
retrieval of module C and complete its job.)
With your approach your log is cluttered with error messages
nevertheless - although it is unnecessary. Or maybe you want to write
a warning, but that should be decided in B’s code - not in the place
that raises the exception.
Kind regards
robert