On Thu, Aug 6, 2009 at 5:31 PM, Christopher Brind<[email protected]> wrote:
> It might appear that the advantage of sub classing RuntimeException would be > that we are able to quickly identify exceptions generated in the Pivot > framework, but this is countered by the fact we have no way to stop > application developers using Pivot also throwing that exception. > Assuming the 'End User' is even able to get their hands on the exception > stack trace, the error reporting flow is likely to be something like: > > End User -> (1st or 2nd line support maybe) -> App Developer -> Pivot Team > > The App Developer is likely to be able to determine if the problem should be > reported to the Pivot team by simply looking at the stack trace. I was thinking more in the line that the exceptions are caught during development and QA of the Pivot application. If it would be possible to do "Install Pivot Reporting Handler" in the "dev/qa mode" of the app, then when QA finds the problem, they effectively just hit the 'report' button and it ends here somehow. People who has worked with IntelliJ's IDEA know what I mean. I might say that a "InternalPivotError extends Error" might discourage enought for others to use, especially if it contains compulsory constructor arguments like "Component"... Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
