[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

What are you suggestions for raising exceptions

dkmd_nielsen

11/7/2008 12:08:00 PM

My application has a common routine to format error messages:

def FLIO.display_error(clss,err)
ln = '-'*70
lbl = "#{clss}_#{sprintf('%04i',err[:num])}"
ln[(ln.length - lbl.length)/2,lbl.length] = (' Error: ' + lbl +
' ')
puts ln,err[:msg],ln
end
....
FLIO.display_error(self.class,
{:num => 5,
:msg => "Test error message"})
raise ArgumentError

Questions:

Should I call the routine to format the message and return to the
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?

Thank you
dvn
1 Answer

Robert Klemme

11/7/2008 2:13:00 PM

0

2008/11/7 dkmd_nielsen <donn@cmscms.com>:
> 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.

> end
> ...
> FLIO.display_error(self.class,
> {:num => 5,
> :msg => "Test error message"})
> raise ArgumentError
>
> Questions:
>
> Should I call the routine to format the message and return to the
> 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

--
remember.guy do |as, often| as.you_can - without end