53

This Debug Apex Code in Eclipse (Generally Available) release note says:

The Apex Debugger extends the Force.com IDE plug-in for Eclipse and behaves similarly to debuggers available for other languages. Use it in sandbox orgs to root out the bugs in your Apex code.

I also see the PDF release notes say "Contact Salesforce to enable" and that additional cost is involved. Yo Force reports a cost of $18,000 a year in their answer.

I'm looking for feedback from someone who has actually used the feature in their normal work. How well does it work? Any gotchas? Has effective debugging support for Apex finally been delivered?

(Mention from earlier this year Force.com IDE Debugger. New feature?)

Improve this question
3
  • It's unfortunate that you've still not received a post from someone who has first-hand experience with the Apex debugger, but instead links to other's reports of their accounts posted elsewhere. That's not to disparage the quality of the links, just an observation that there's no response from someone with actual experience as yet as asked for in your post.
    – crmprogdev
    Dec 8, 2015 at 15:02
  • 1
    I've used it in passing and it felt like a competent debugger, although at times it took a minute or two to start a session (I guess the pod was busy?). All the basics like variable inspection and step into/over/out worked well as far as I saw. I linked this post to somebody who used it much more than I did in hopes they'll share.
    – ca_peterson
    Jan 14, 2016 at 4:09
  • 1
    I've used it and have left an answer below. Hopefully my my answer adds a little more info.
    – Caspar Harmer
    Jan 14, 2016 at 20:27

4 Answers 4

Reset to default
16

I convinced my PM that I needed the debugger for my recent project. I have not really used it much however, as I ended up doing so much front end work. Also, with lots of unit tests, you don't need it as much either.

One thing that was very annoying was that any time metadata on the project gets saved, your session gets killed. Which was a lot.

However, in general, the debugger works very well.

  • It is pretty fast (maybe 1-2 seconds to stop at a break point)
  • It works for triggers
  • It works on Page controllers - ie, you visit the page with the break point enabled, and it catches it no probs.
  • It even works for Apex lightning controllers ( I am using an embedded lightning lookup component that I built in my VisualForce page )

Here is the evidence: picture of code being debugged by force.com debugger

Caveats:

It does not work currently with Eclipse 4.5 (for me anyway). The entire Force.com environment failed to load.

Also make sure you follow the process described here. I had a lot of trouble with the debugger until I followed this process exactly (I initially just made a Force.com debug configuration and started a session without setting up the perspective first as described in the above webpage - it failed to stop at any of my break points)

And finally, yeah, I think it's costing over 1200 a month, which given how much I've used it is probably not worth it, unfortunately. However, given a different project and different mix of coding tasks, it could be extremely useful.

Improve this answer
31

Some points from the DF15 presentation that Nate linked to.

  • You can only have 2 active debugger threads in an Org.
  • You can't, currently, debug asynchronous code (some allowances for test contexts)
  • It's only available via the Eclipse Debugger Plugin. There is an API, but it is still in flux and isn't going to be made public yet.
  • The Debugger is an Add-On Product because:
    • It is a very limited resource
    • Every debugging session is a transaction that lasts up to 30 minutes
    • Each transaction needs a thread and a database connection
  • Debugger sessions are only available in Sandboxes orgs
    • They have the available capacity where as productions orgs are tuned for performance
    • Debugger Sessions are shared across your pool of sandboxes

So, if:

  • you are happy using Eclipse as an IDE,
  • can get someone to talk to your Account Executive to get it turned on,
  • can afford however much it costs for the add on feature (See @Yo Force's answer for sample pricing),
  • are debugging in a Sandbox,
  • and only need two active debugging sessions at any one time

Then I'd say it is a great feature as demoed.

In terms of actual usage, Chris Peterson has some comments on it in the Code Coverage podcast.

January 2016 - There are some more details in the blog post The Apex Interactive Debugger. This includes how an ISV might be able to debug in the subscriber Org and how it might be possible to create a sandbox from a developer edition org.

Improve this answer
16

The answer I got from My Account Executive: The cost is 18,000 USD a year and it requires some internal approvals before it can be sold...

Improve this answer
3
  • 4
    I can verify this, got the same quote from my account exec as well. Though I have to say, I'm annoyed that they would put a price tag on an essential development tool like this. If they have concerns about abusing server resources, there are other safety mechanisms that can be built that are more appropriate than charging more for an already overpriced system.
    – smohyee
    Dec 11, 2015 at 17:15
  • 1
    The approvals are to ensure we don't oversell the feature on any one pod. There's a limit to the capacity we can offer, though we are working on increasing the maximum capacity. We looked at lots of other "safety mechanisms" and determined that they would make the feature very difficult to use. I tried to give more detail in my blog post here: developer.salesforce.com/blogs/engineering/2016/01/…
    – Josh Kaplan
    Jan 8, 2016 at 17:15
  • 4
    @JoshKaplan, I just read your blog post and I appreciate your explanations. $18k/year for stopped thread debugging (!!!) is a lot more palatable as long as I embrace your narrative of 'this is temporary as we figure out how to scale better'. Gloomier prediction: SF will not actually remove or significantly reduce the price once the technical limitations have been resolved, as the business model is more about gouging customers who are already too invested, rather than providing fair value for price up front (see the cost if you want a 26th custom tab in EE...). Hopefully I'm proven wrong!
    – smohyee
    Feb 1, 2016 at 21:50
12

Not an answer:

But here's the DF15 presentation: https://www.youtube.com/watch?v=O2TvQ3rtpV0

As mentioned at 18:30 it's an add on product (for purchase).

Improve this answer
11
  • 6
    Hopefully no one will pay the absurd price and it will become free like flows did. It should not be a feature but rather a required took to properly develop on the platform
    – Eric
    Oct 6, 2015 at 21:18
  • 1
    @Eric I think part of the reasoning to keep it a paid feature was to minimize the performance impact it will have on the rest of the system. I.e. only those who really need it and can afford it will use it.
    – Daniel Ballinger
    Oct 7, 2015 at 0:52
  • 6
    @DanielBallinger - The impact is only related to the specific org using it. It is isolated and has no impact on any other tenant. The reasoning is purely financial as there are many features that would bring down an org if used improperly......Although I do agree that they need to have some checks and balances in place. One would be to disallow login to the org while debugging except for the admin (or requestor) and the person for who the trace is set for. (In production). In fact, I do not think it should even be allowed in production but should be free and available only in sandboxes.
    – Eric
    Oct 7, 2015 at 0:57
  • 2
    Guys, I am demoing the debugger on the Winter 16 webinar next Tuesday. No pricing, only functionality. @Eric
    – Jeff Douglas
    Oct 7, 2015 at 21:05
  • 2
    @Eric the impact is pod-wide, not isolated to the org that is debugging. When you have a thread stopped for debugging, you are essentially decreasing the capacity of the whole instance by some amount. It does not take too many people sitting on a breakpoint concurrently to make a material difference in service availability. This can't be free-for-all in the multitenant environment. For more details, please check my blog post: developer.salesforce.com/blogs/engineering/2016/01/…
    – Josh Kaplan
    Jan 8, 2016 at 17:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .