Improve errors while building depenencies


Currently, when WireBox encounters an error while building a dependency, "death by information" occurs. Generally an error message is generated that is so large (often containing entire serialized CFCs and full stack traces) that there is no hope of every being able to decipher it.

Simplify the JSON data for things such as constructor args to not serialize CFCs or large data types. perhaps, just include the name of the datatype for anything other than simple values, and then even truncate those.
Also, don't include the entire stack trace in the message as it is wholly unreadable. Perhaps just pick out the top couple files and line numbers from the tag stack and rely on LogBox to capture the entire "caught" error.

Here is an example of an error. Note, this is JUST the message of the error. I am not including the stack trace.


Dominic Watson
August 7, 2014, 6:00 PM

My vote here is for Wirebox NOT to catch and rethrow any errors at all. The issue with catching the error and throwing it again is that the TagContext gets foreshortened, losing vital information.

I would like the try and catch to be removed from /ioc/Builder.cfc:


Brad Wood
August 8, 2014, 12:29 AM

the problem with not try/catching the error is that it makes debugging impossible. For instance, this text at the beginning of the error "Error building: handlers.Main" would be impossible to know. Let's say you have a site with 200 models and somewhere, one of them had an error building one of their dependencies. You would have no idea at all where the problem existed because the original stack trace is just buried somewhere inside of WireBox and the tag stack can be very, very, very long depending on how nested your dependencies are. Our first pass at this was to just enable debug logging, but all that did was dump thousands of lines of info into a log file that was almost impossible to sift through.

What would be REALLY nice is if ColdFusion let us throw exceptions with a "cause" like Java works. But in the mean time, rethrowing the error is the only way to have a hope of debugging it, but we just need to simplify the amount of crap we're putting in there.

Dominic Watson
August 8, 2014, 12:35 AM

For me its the other way around, debugging is impossible because the actual point where the error is thrown is masked. I know that happened somewhere during the init of service-x, but that's it.

Without catching it, I can get straight to the problematic code by looking at the tag context.

You lose the part about "Wirebox had a problem initing model X", but you gain getting straight to the point of the error which is the most important part imo.



Luis Majano


Brad Wood



Fix versions