Right now when you call sys::Err.trace is caps the depth to 20 and then prints "More...".

99% of the time the rest of the trace is noise, but 1% you really need to see all the way down.

Maybe we might want a maxDepth on trace?

What do you guys think?

I've run into this as well a time or two. So this seems reasonable. I assume you'll default it to 20?

Usually when there's more it's because execution went into, then out of, some FFI, and you see a whole boatload of org.eclipse internals. If you wanted to get fancy about it, having an option to show or hide those might be cute.

Really though, maxDepth would be fine, for the times when you need to see how you got into this mess, not just where you ended up.

Java stack-traces often get unnecessary long because they start to cycle, would Fan be able to detect this and perhaps cap there along with a cycle notification?

Java stack-traces often get unnecessary long because they start to cycle, would Fan be able to detect this and perhaps cap there along with a cycle notification?

That would nice, but I think it might be an orthogonal features. Sometimes stack traces are really long and don't cycle - so I don't think it is a general solution to this problem.

Yes. It's rarely useful to go that deep. In java when I work with SAP software which has a gazillion layers I sometime go that deep, but it's rarely where the useful stuff is (it's probably going to be web server / struts stuff this deep).

What's way more useful 99% of times(in java) is to skip down to the "caused by" traces. Fan doesn't seem to do exception chaining so I guess it's not relevant.

I suppose without checked exceptions, exception chaining is probably not needed ?

I think you are right about that tcolar. While both Java and C# does exception chaining, I find C# traces much smaller and to-the-point. Of course, the fact that Java does not support rethrows could also have something to do with it.

What's way more useful 99% of times(in java) is to skip down to the "caused by" traces. Fan doesn't seem to do exception chaining so I guess it's not relevant.

Actually Fan does do exception chaining. Although typically it is never deeper than 1 or 2 b/c of unchecked exceptions:

fansh> NullErr("a", CastErr("b")).trace
sys::NullErr: a
  sh0::FanshEval._eval (fansh/:5)
  sun.reflect.NativeMethodAccessorImpl.invoke0 (Unknown)
  sun.reflect.NativeMethodAccessorImpl.invoke (Unknown)
  ...
  fanx.tools.Fan.run (Fan.java:241)
  fanx.tools.Fan.main (Fan.java:279)
Cause:
  sys::CastErr: b
    sh0::FanshEval._eval (fansh/:5)
    sun.reflect.NativeMethodAccessorImpl.invoke0 (Unknown)
    ...
    fansh::Evaluator.eval (Evaluator.fan:112)
    fansh::Shell.run (Shell.fan:45)

Today all nested exceptions use same maxStack of 20 and just indented. If we added maxStack then I think it would apply to all chained exceptions too.

I somehow missed the "cause" in the Exception page.

Anyway as long as it's 20 PER "cause", it sounds good.

I decided to leave it a bit more open ended and use an options map:

**
** Dump the stack trace of this exception to the specified
** output stream (or Sys.out by default).  Return this.
**
** The options may be used to specify the format of the output:
**   - "maxDepth": Int specifies how many methods in each
**        exception of chain to include.  If unspecified the
**        default is 20.
**
This trace(OutStream out := Sys.out, [Str:Obj]? options := null)