1

I've put the code which processes document generation to lib/parser folder in my Rails application. But now I can't debug that code: neither binding.pry nor byebug have an effect. Raising exceptions also doesn't show up neither in logs nor in rails server's stdout channel. Is there any way to fine-tune it, or to debug it I have to put it somewhere else?

The module itself is included in controller with 

require Rails.root.join("lib/parser/parser.rb")
ProdoElmit
  • 1,067
  • 9
  • 22
  • That requires the file, it doesn't include any methods in the controller. – j-dexx Mar 30 '16 at 15:56
  • @j-dexx but why does that work then? – ProdoElmit Mar 30 '16 at 15:58
  • Why does what work then? – j-dexx Mar 30 '16 at 16:00
  • @j-dexx all of the logic in `lib/parser`. How does not including the methods in the controller correlate with breakpoints not being triggered? – ProdoElmit Mar 30 '16 at 16:07
  • What you have done is say I want to use this file. You've not at any point said include these methods in the controller based on the code you provided. If you can post the full code then we'll be able to help you more. You'll need to do something like `include Parser` – j-dexx Mar 30 '16 at 16:08

2 Answers2

1

You can relaunch your server after each change and it will work but if you have a lot of code it can be long.

You can also add your code in the autoload_paths (into application.rb) :

config.autoload_paths += Dir[Rails.root.join('lib', '**/')]

See also Auto-loading lib files in Rails 4

Naremy
  • 491
  • 8
  • 22
  • I understand that, but the question is that I can't use debuggers in that code, which would help me a lot to understand what's going wrong – ProdoElmit Mar 30 '16 at 16:08
  • You mean if you write a binding.pry in your main home controller action, it does not have effect? If it's the case it's not related to the lib folder but related to your use of binding.pry. In the other case, it's probably due to the fact that the code in not reloaded. It expect that it's a reloading concern cause you write that raising exception does not have effect. – Naremy Mar 30 '16 at 16:14
  • no, I put `binding.pry` in one of functions in `lib/parser/parser.rb`. It works if it's in controller, but not there. – ProdoElmit Mar 30 '16 at 16:24
  • Ok, so no output, raise nor binding event after a restart. I know that not the answer you want but your code is probably not called. Start by ensure that your code is loaded, just make a raise in your main function or initializer class, launch a raise console and see if it crash. – Naremy Mar 30 '16 at 16:49
  • but the logic itself works, so it's called properly. Can't post the code right now. – ProdoElmit Mar 30 '16 at 16:53
  • hmm, you were right. The problem was that I was catching the error, thus it didn't show in `rails server` output. Thank you! And sorry for stupid questions ) – ProdoElmit Mar 30 '16 at 18:18
1

Thanks to @Naremy, I've found my mistake. The problem was following: I've had begin...rescue block which was catching errors stopping them from floating up to output of rails server. And as the error was the same as in the other chunk of code (where I was trying to set breakpoint), I couldn't find it. So removing rescue made a move, and now everything works as expected.

So the overall fact is: if you catch a error, neither rails server output nor better_errors gem will show you anything.

ProdoElmit
  • 1,067
  • 9
  • 22