1

I am trying to build a perl remote debug config in IntelliJ to test a codebase I am ssh into, but I have no idea what to put for the values. I could really use an example. I want to run it so the site actually going up, but I can step through it using my intellij debug console. entry fields for config. I have tried every reasonable value I can, and none work. I have looked at the documentation, and it may be some of the worst I have ever seen. Is there anyone out there who has done something like this before that could tell me how to fill out those fields with examples?

Aris Emery
  • 19
  • 3

1 Answers1

0

This question has been around for a long time, and I'm actually perusing the questions on this site for the same thing. A helpful thread from 2008 here might help you decide what's suitable.

Some things to keep in mind:

  1. Going too crazy with levels might get confusing and hard to track.
  2. Being too stringent on levels might cause you to wither stratify logging you don't want or canx logging that you do.
  3. Consistency is key throughout your application.
  4. All members of your team need to be on the same page when it comes to error protocol/tiers/etc.

That being said, here's what I'm thinking for me:

  • (Optional) -1, No logging... generally a bad idea, but a customer might want it.
  • 0, Critical and Fatal Errors - These tend to halt the program or cause major rupture of processes.
  • 1, Errors - These are other errors, but these impact something minor/superficial/cosmetic.
  • 2, Warnings - You were able to stave off the apocalypse, but you had to revert to default values or massage data to do it. Generally something that some of your user base might want/need to know about.
  • 3, Informational - This is getting into where users don't care about it as much unless you've geared it toward something team leads or decision makers are interested in. We are now getting away from the End User.
  • 4, Operational - Program flow entries of important and critical processes, possibly with focus on major functions/modules. We have now branched into where leadership of dev teams are interested, and thus team members themselves. This is also pretty much your first actual debug level, but not quite where the rubber meets the road.
  • 5-?, Debug levels - Increasingly verbose as you drill down into processes, varaible definitions and data flow, and data transformation.
  • LAST LEVEL, Trace - This is your printline in between everything not already flagged with a debug level. You are asking the application to report every step of the way. These entries likely have a lot of extraneous header information or vary wildly in formats.

Give that article a read, and poke around this site. Let it marinate a bit before you jump headlong so you've a plan before your approach. Good luck, I hope this helps.

hendripd
  • 36
  • 6