Forum: Ruby What are you suggestions for raising exceptions

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
dkmd_nielsen (Guest)
on 2008-11-07 14:11
(Received via mailing list)
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
Robert K. (Guest)
on 2008-11-07 16:15
(Received via mailing list)
2008/11/7 dkmd_nielsen <removed_email_address@domain.invalid>:
> 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
This topic is locked and can not be replied to.