Hi there, I''m using Log4r in my rails projects. On log.error an email is sent using the EmailOutputter. I know changed the EmailOutputter to include a global var in the subject (MDC) since the subject is normally static. I want to set this var to the exception message, so it is sent as the subject. Can anyone tell me how to do this in rails? Basically: raise e or some other cause> -> Log4r::MDC.put(''subject'', e.message) > continue with the exceptionI found *rescue_from* but it just gives it to the handler and then stops. Thanks a lot, Christoph -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/7baf66e8-c61c-4757-90b1-3c9712f6297b%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Hi Christoph,
All you need to do is re-raise the exception after you''re done using it
in
your rescue_from, so something along the lines of:
$ cat ./app/controllers/foo_controller.rb
...
rescue_from Exception do |e|
# do something with e before re-raising it ...
Rails.logger.debug("TEST: before re-raising ... e=#{e.inspect}")
raise e
end
...
def testfoo
x = ''bar'' if 1/0
....
end
....
$ curl -sLi http://foo.localhost/testfoo
...
$ cat ./log/development.log
...
[c55f5] TEST: before re-raising ... e=#<ZeroDivisionError: divided by 0>
[c55f5] Completed 500 Internal Server Error in 17ms
[c55f5]
ZeroDivisionError (divided by 0):
app/controllers/foo_controller.rb:89:in `/''
app/controllers/foo_controller.rb:89:in `testfoo''
...
Jeff
On Tuesday, November 12, 2013 6:40:12 AM UTC-8, sol
wrote:>
> Hi there,
>
> I''m using Log4r in my rails projects. On log.error an email is
sent using
> the EmailOutputter.
> I know changed the EmailOutputter to include a global var in the subject
> (MDC) since the subject is normally static.
>
> I want to set this var to the exception message, so it is sent as the
> subject.
>
> Can anyone tell me how to do this in rails?
>
> Basically:
>
> raise e or some other cause
>> -> Log4r::MDC.put(''subject'', e.message)
>> continue with the exception
>
>
> I found *rescue_from* but it just gives it to the handler and then stops.
>
> Thanks a lot,
> Christoph
>
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/c3f25e2c-240d-4567-9058-a4c0b6c1232d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Hi Jeff, thanks for your reply! I found the article here: http://www.simonecarletti.com/blog/2009/11/re-raise-a-ruby-exception-in-a-rails-rescue_from-statement/ And he mentions that re-raising does not work since rails won''t catch it anymore.. has this been changed since? I generally thought there might be a better way, as usually re-raising exceptions is considered to be bad :) Thanks a lot, Christoph On Tuesday, 12 November 2013 19:07:00 UTC+1, Jeff Lewis wrote:> > Hi Christoph, > > All you need to do is re-raise the exception after you''re done using it in > your rescue_from, so something along the lines of: > > $ cat ./app/controllers/foo_controller.rb > ... > rescue_from Exception do |e| > # do something with e before re-raising it ... > Rails.logger.debug("TEST: before re-raising ... e=#{e.inspect}") > raise e > end > ... > > def testfoo > x = ''bar'' if 1/0 > .... > end > .... > > $ curl -sLi http://foo.localhost/testfoo > ... > > $ cat ./log/development.log > ... > [c55f5] TEST: before re-raising ... e=#<ZeroDivisionError: divided by 0> > [c55f5] Completed 500 Internal Server Error in 17ms > [c55f5] > ZeroDivisionError (divided by 0): > app/controllers/foo_controller.rb:89:in `/'' > app/controllers/foo_controller.rb:89:in `testfoo'' > ... > > Jeff > > On Tuesday, November 12, 2013 6:40:12 AM UTC-8, sol wrote: >> >> Hi there, >> >> I''m using Log4r in my rails projects. On log.error an email is sent using >> the EmailOutputter. >> I know changed the EmailOutputter to include a global var in the subject >> (MDC) since the subject is normally static. >> >> I want to set this var to the exception message, so it is sent as the >> subject. >> >> Can anyone tell me how to do this in rails? >> >> Basically: >> >> raise e or some other cause >>> -> Log4r::MDC.put(''subject'', e.message) >>> continue with the exception >> >> >> I found *rescue_from* but it just gives it to the handler and then stops. >> >> Thanks a lot, >> Christoph >> >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/b4a43f59-757b-4761-bd26-74b1ef12f714%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Hi Christoph, My (simple) example was just trying to give you an idea of how to do what you were asking using rescue_from. And note that the log does show that the re-raising worked as expected, where we did something with the caught exception first (ie write a debug TEST line to the log) before then re-raising it and letting the rails env stack handle it (ie log shows the stacktrace including the orig line where the bug is in the code, ...). As for "a better way", it always depends on what you''re ultimately trying to accomplish and the tradeoffs for getting there. But if you really did want to use rescue_from for any/all exceptions/errors that could occur, then at a minimum you''re going to want to make sure that what you do with that caught exception (ie your Log4r::MDC... call) doesn''t itself result in any exceptions/errors. One way would be to wrap that work in a begin ... rescue Exception => e2 ... end ... before then re-raising the originally caught exception. Jeff On Tuesday, November 12, 2013 11:26:47 AM UTC-8, sol wrote:> > Hi Jeff, thanks for your reply! > > I found the article here: > > http://www.simonecarletti.com/blog/2009/11/re-raise-a-ruby-exception-in-a-rails-rescue_from-statement/ > > And he mentions that re-raising does not work since rails won''t catch it > anymore.. > has this been changed since? > > I generally thought there might be a better way, as usually re-raising > exceptions is considered to be bad :) > > Thanks a lot, > Christoph > > On Tuesday, 12 November 2013 19:07:00 UTC+1, Jeff Lewis wrote: >> >> Hi Christoph, >> >> All you need to do is re-raise the exception after you''re done using it >> in your rescue_from, so something along the lines of: >> >> $ cat ./app/controllers/foo_controller.rb >> ... >> rescue_from Exception do |e| >> # do something with e before re-raising it ... >> Rails.logger.debug("TEST: before re-raising ... e=#{e.inspect}") >> raise e >> end >> ... >> >> def testfoo >> x = ''bar'' if 1/0 >> .... >> end >> .... >> >> $ curl -sLi http://foo.localhost/testfoo >> ... >> >> $ cat ./log/development.log >> ... >> [c55f5] TEST: before re-raising ... e=#<ZeroDivisionError: divided by 0> >> [c55f5] Completed 500 Internal Server Error in 17ms >> [c55f5] >> ZeroDivisionError (divided by 0): >> app/controllers/foo_controller.rb:89:in `/'' >> app/controllers/foo_controller.rb:89:in `testfoo'' >> ... >> >> Jeff >> >> On Tuesday, November 12, 2013 6:40:12 AM UTC-8, sol wrote: >>> >>> Hi there, >>> >>> I''m using Log4r in my rails projects. On log.error an email is sent >>> using the EmailOutputter. >>> I know changed the EmailOutputter to include a global var in the subject >>> (MDC) since the subject is normally static. >>> >>> I want to set this var to the exception message, so it is sent as the >>> subject. >>> >>> Can anyone tell me how to do this in rails? >>> >>> Basically: >>> >>> raise e or some other cause >>>> -> Log4r::MDC.put(''subject'', e.message) >>>> continue with the exception >>> >>> >>> I found *rescue_from* but it just gives it to the handler and then >>> stops. >>> >>> Thanks a lot, >>> Christoph >>> >>-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/1f8eae3c-4927-4398-8e2e-d432bc1eaca7%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Thanks a lot Jeff, Yeah I saw it works, that''s why I wondered about the linked post.. Anyway, I''m just trying to basically get emails that contain the exception/error message in the subject so it''s easier to sort if there are many error mails. Of course the rescue_from method only targets one specific case - the one where I get a rails exception. But I think I cannot do it by monkey patching log4r as rails already sends a complete (and formatted) string to log.error making it hard to extract the relevant message. I''ll see how I can use it, but I think I can get there somehow :) Thank a lot for your suggestion! Christoph On Tuesday, 12 November 2013 21:25:30 UTC+1, Jeff Lewis wrote:> > Hi Christoph, > > My (simple) example was just trying to give you an idea of how to do what > you were asking using rescue_from. > > And note that the log does show that the re-raising worked as expected, > where we did something with the caught exception first (ie write a debug > TEST line to the log) before then re-raising it and letting the rails env > stack handle it (ie log shows the stacktrace including the orig line where > the bug is in the code, ...). > > As for "a better way", it always depends on what you''re ultimately trying > to accomplish and the tradeoffs for getting there. > > But if you really did want to use rescue_from for any/all > exceptions/errors that could occur, then at a minimum you''re going to want > to make sure that what you do with that caught exception (ie your > Log4r::MDC... call) doesn''t itself result in any exceptions/errors. One > way would be to wrap that work in a begin ... rescue Exception => e2 ... > end ... before then re-raising the originally caught exception. > > Jeff > > > On Tuesday, November 12, 2013 11:26:47 AM UTC-8, sol wrote: >> >> Hi Jeff, thanks for your reply! >> >> I found the article here: >> >> http://www.simonecarletti.com/blog/2009/11/re-raise-a-ruby-exception-in-a-rails-rescue_from-statement/ >> >> And he mentions that re-raising does not work since rails won''t catch it >> anymore.. >> has this been changed since? >> >> I generally thought there might be a better way, as usually re-raising >> exceptions is considered to be bad :) >> >> Thanks a lot, >> Christoph >> >> On Tuesday, 12 November 2013 19:07:00 UTC+1, Jeff Lewis wrote: >>> >>> Hi Christoph, >>> >>> All you need to do is re-raise the exception after you''re done using it >>> in your rescue_from, so something along the lines of: >>> >>> $ cat ./app/controllers/foo_controller.rb >>> ... >>> rescue_from Exception do |e| >>> # do something with e before re-raising it ... >>> Rails.logger.debug("TEST: before re-raising ... e=#{e.inspect}") >>> raise e >>> end >>> ... >>> >>> def testfoo >>> x = ''bar'' if 1/0 >>> .... >>> end >>> .... >>> >>> $ curl -sLi http://foo.localhost/testfoo >>> ... >>> >>> $ cat ./log/development.log >>> ... >>> [c55f5] TEST: before re-raising ... e=#<ZeroDivisionError: divided by 0> >>> [c55f5] Completed 500 Internal Server Error in 17ms >>> [c55f5] >>> ZeroDivisionError (divided by 0): >>> app/controllers/foo_controller.rb:89:in `/'' >>> app/controllers/foo_controller.rb:89:in `testfoo'' >>> ... >>> >>> Jeff >>> >>> On Tuesday, November 12, 2013 6:40:12 AM UTC-8, sol wrote: >>>> >>>> Hi there, >>>> >>>> I''m using Log4r in my rails projects. On log.error an email is sent >>>> using the EmailOutputter. >>>> I know changed the EmailOutputter to include a global var in the >>>> subject (MDC) since the subject is normally static. >>>> >>>> I want to set this var to the exception message, so it is sent as the >>>> subject. >>>> >>>> Can anyone tell me how to do this in rails? >>>> >>>> Basically: >>>> >>>> raise e or some other cause >>>>> -> Log4r::MDC.put(''subject'', e.message) >>>>> continue with the exception >>>> >>>> >>>> I found *rescue_from* but it just gives it to the handler and then >>>> stops. >>>> >>>> Thanks a lot, >>>> Christoph >>>> >>>-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/cd998fe6-eaa4-4bc4-a486-0336d68c71b2%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
I''ve used the above approach now However, this only works for controller actions. I''ve got some cronjobs in the project (lib folder) as well as a sinatra app that is mounted within the rails app. Is there any way I could catch the exceptions in these parts as well? Thanks, Christoph On Tuesday, 12 November 2013 21:32:04 UTC+1, sol wrote:> > Thanks a lot Jeff, > > Yeah I saw it works, that''s why I wondered about the linked post.. > > Anyway, I''m just trying to basically get emails that contain the > exception/error message in the subject so it''s easier to sort > if there are many error mails. > > Of course the rescue_from method only targets one specific case - the one > where I get a rails exception. > But I think I cannot do it by monkey patching log4r as rails already sends > a complete (and formatted) string to > log.error making it hard to extract the relevant message. > > I''ll see how I can use it, but I think I can get there somehow :) > > Thank a lot for your suggestion! > Christoph > > On Tuesday, 12 November 2013 21:25:30 UTC+1, Jeff Lewis wrote: >> >> Hi Christoph, >> >> My (simple) example was just trying to give you an idea of how to do what >> you were asking using rescue_from. >> >> And note that the log does show that the re-raising worked as expected, >> where we did something with the caught exception first (ie write a debug >> TEST line to the log) before then re-raising it and letting the rails env >> stack handle it (ie log shows the stacktrace including the orig line where >> the bug is in the code, ...). >> >> As for "a better way", it always depends on what you''re ultimately trying >> to accomplish and the tradeoffs for getting there. >> >> But if you really did want to use rescue_from for any/all >> exceptions/errors that could occur, then at a minimum you''re going to want >> to make sure that what you do with that caught exception (ie your >> Log4r::MDC... call) doesn''t itself result in any exceptions/errors. One >> way would be to wrap that work in a begin ... rescue Exception => e2 ... >> end ... before then re-raising the originally caught exception. >> >> Jeff >> >> >> On Tuesday, November 12, 2013 11:26:47 AM UTC-8, sol wrote: >>> >>> Hi Jeff, thanks for your reply! >>> >>> I found the article here: >>> >>> http://www.simonecarletti.com/blog/2009/11/re-raise-a-ruby-exception-in-a-rails-rescue_from-statement/ >>> >>> And he mentions that re-raising does not work since rails won''t catch it >>> anymore.. >>> has this been changed since? >>> >>> I generally thought there might be a better way, as usually re-raising >>> exceptions is considered to be bad :) >>> >>> Thanks a lot, >>> Christoph >>> >>> On Tuesday, 12 November 2013 19:07:00 UTC+1, Jeff Lewis wrote: >>>> >>>> Hi Christoph, >>>> >>>> All you need to do is re-raise the exception after you''re done using it >>>> in your rescue_from, so something along the lines of: >>>> >>>> $ cat ./app/controllers/foo_controller.rb >>>> ... >>>> rescue_from Exception do |e| >>>> # do something with e before re-raising it ... >>>> Rails.logger.debug("TEST: before re-raising ... e=#{e.inspect}") >>>> raise e >>>> end >>>> ... >>>> >>>> def testfoo >>>> x = ''bar'' if 1/0 >>>> .... >>>> end >>>> .... >>>> >>>> $ curl -sLi http://foo.localhost/testfoo >>>> ... >>>> >>>> $ cat ./log/development.log >>>> ... >>>> [c55f5] TEST: before re-raising ... e=#<ZeroDivisionError: divided by 0> >>>> [c55f5] Completed 500 Internal Server Error in 17ms >>>> [c55f5] >>>> ZeroDivisionError (divided by 0): >>>> app/controllers/foo_controller.rb:89:in `/'' >>>> app/controllers/foo_controller.rb:89:in `testfoo'' >>>> ... >>>> >>>> Jeff >>>> >>>> On Tuesday, November 12, 2013 6:40:12 AM UTC-8, sol wrote: >>>>> >>>>> Hi there, >>>>> >>>>> I''m using Log4r in my rails projects. On log.error an email is sent >>>>> using the EmailOutputter. >>>>> I know changed the EmailOutputter to include a global var in the >>>>> subject (MDC) since the subject is normally static. >>>>> >>>>> I want to set this var to the exception message, so it is sent as the >>>>> subject. >>>>> >>>>> Can anyone tell me how to do this in rails? >>>>> >>>>> Basically: >>>>> >>>>> raise e or some other cause >>>>>> -> Log4r::MDC.put(''subject'', e.message) >>>>>> continue with the exception >>>>> >>>>> >>>>> I found *rescue_from* but it just gives it to the handler and then >>>>> stops. >>>>> >>>>> Thanks a lot, >>>>> Christoph >>>>> >>>>-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/e7583a34-f68f-434b-9efc-5d96cf5ee2a0%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
On Friday, November 15, 2013 10:26:10 AM UTC, sol wrote:> > I''ve used the above approach now > > However, this only works for controller actions. > I''ve got some cronjobs in the project (lib folder) as well as a sinatra > app that is mounted within the rails app. > > Is there any way I could catch the exceptions in these parts as well? > > For a cronjob type thing it''s up to you to wrap your script with somethingthat will log the error. My cronjobs normally end up looking like TaskWrapper(''some job'') do #work here end and elsewhere def TaskWrapper begin yield rescue Exception => ex #do something with the exception raise end end I use rescue Exception because for once I think it''s appropriate that things like SyntaxError are caught so that I can be notified about them For the sinatra (or even the rails case) you could write a rack middleware that would look something like class ErrorNotifier def initialize(app) @app = app end def call(env) begin @app.call(env) rescue Exception => ex #do something with the exception raise end end end You could also render an error message if you want to override that. You might also be interested in the exception handling stuff described at http://blog.plataformatec.com.br/2012/01/my-five-favorite-hidden-features-in-rails-3-2/ Fred -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/cd9ccbb1-6ef4-48ba-bdee-e9a783e6f287%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Thanks a lot! That''s useful On Saturday, 16 November 2013 22:36:35 UTC+1, Frederick Cheung wrote:> > > > On Friday, November 15, 2013 10:26:10 AM UTC, sol wrote: >> >> I''ve used the above approach now >> >> However, this only works for controller actions. >> I''ve got some cronjobs in the project (lib folder) as well as a sinatra >> app that is mounted within the rails app. >> >> Is there any way I could catch the exceptions in these parts as well? >> >> For a cronjob type thing it''s up to you to wrap your script with > something that will log the error. My cronjobs normally end up looking like > > TaskWrapper(''some job'') do > #work here > end > > and elsewhere > > def TaskWrapper > begin > yield > rescue Exception => ex > #do something with the exception > raise > end > end > > I use rescue Exception because for once I think it''s appropriate that > things like SyntaxError are caught so that I can be notified about them > > For the sinatra (or even the rails case) you could write a rack middleware > that would look something like > > class ErrorNotifier > def initialize(app) > @app = app > end > > def call(env) > begin > @app.call(env) > rescue Exception => ex > #do something with the exception > raise > end > end > end > > > You could also render an error message if you want to override that. > > You might also be interested in the exception handling stuff described at > http://blog.plataformatec.com.br/2012/01/my-five-favorite-hidden-features-in-rails-3-2/ > > Fred >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/68616ea1-d09e-4b2b-a8b2-8e844fbae616%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.