I am working on a project in PHP that does a lot of input validation and can throw different custom exception classes in various layers of the application. To make the project code easier to read, I've displaced all the validation code into static methods of a validation class, which performs the check and throws the appropriate exception if necessary. My problem is, the exception stacktrace displays the entire call stack down into the validation class, but I feel like the extra information is not helpful and will only serve to confuse someone trying to debug the location of the real problem. Should I simply rely on informative exception messages or is it possible to trim the trace log in some way.
3
-
Just to clarify: you're looking for what the appropriate thing to do here is, not how to implement something? If so, this is on-topic here.– user8Commented Jan 2, 2012 at 21:24
-
@MarkTrapp Correct. I want to know if this is potentially the wrong approach (parsing the stack trace to remove call overhead for 'irrelevant' method calls) or if there is a standard way of dealing with this problem. Perhaps SE would be better suited.– leoCommented Jan 2, 2012 at 21:39
-
You're in the right place. However, if had been looking for the code to implement a specific approach, you'd want to ask on our sister site, Stack Overflow, instead.– user8Commented Jan 2, 2012 at 21:49
Add a comment
|
2 Answers
Even if you could, I don't think you should mess with the stack trace. It messes with the programmer's mental model of how exceptions work. When I look at the top line of an exception trace, I expect to see a throw.
Any time you do something that's not "expected", it takes me (ie someone using your library) time to figure out what's actually going on. By keeping surprises to an absolute minimum, you make using your library easier and more intuitive.
Plus, I'd be really, really surprised if you were using set_exception_handler from an input validation library!
answered Jan 2, 2012 at 21:33
-
Yeah. The more I think about it the more I feel like this may be overkill. I want to keep the library as user-friendly as possible, but I don't want to get too crazy. I think I'll just pass invalid parameters into the exception message so the error line is easier to spot.– leoCommented Jan 2, 2012 at 21:47
-
@YannisRizos yeah, a project-wide set_custom_handler would be OK. Commented Jan 2, 2012 at 23:02
A possible workaround would be a project wide custom exception handler, via set_exception_handler(), where you could get the trace array from Exception::getTrace() and show whatever you want to show.
But I don't really see what the problem is, a stack trace is supposed to show you the full path from where you are to where the exception was thrown. I don't really think there's anything confusing about that.
Although it doesn't really answer your question, take a look at xdebug, at the very least it prettifies traces.
