You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2017/03/24 09:30:53 UTC
Don't throw Exceptions during Bootstrap
Gang,
I was just thinking;
We want it to become more efficient to find the runtime problems. One of
the major problems is that one gets an exception after exception the first
time we try to get going with a new project or a new subsystem in an
existing project. And this start->exception->edit->compile cycle is tedious
and not fun.
Suggestion;
1. Introduce a "bootstrapPhase" somewhere.
2. Enhance ConstructionException with exact details of everything going on.
3. Make the ConstructionException constructor private and introduce a
public static method to be called.
4. If Application.mode() is development or test, and bootstrapPhase is
true, then add the Exception to a ThreadLocal list, otherwise throw
exception as previously.
5. Figure out when bootstrap phase is "over", check if there are any
Excepitons in the list, if so, generate an elaborate, machine readable
report (for tooling) and abort. Otherwise clear bootstrapPhase and continue
as normal.
I am not sure if all structural problems can be caught in one swoop or not,
but I am sure it would be a big improvement. Also, there might be other
Exceptions that should be involved in this as well.
WDYT?
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
Re: Don't throw Exceptions during Bootstrap
Posted by Niclas Hedhman <ni...@hedhman.org>.
Now, I just need to figure out why some tests are failing because of my
deferral of reporting. Probably wrong kind of exceptions thrown in many
cases.
On Mon, Apr 3, 2017 at 7:14 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Right, but I am still not sure clarity increases, since generic types
> variants can't override each other there is no ambiguity. I think I want to
> keep the types without package names and without generic type information.
>
> On Mon, Apr 3, 2017 at 2:09 AM, Paul Merlin <pa...@apache.org> wrote:
>
>> Le 2017-03-31 05:02, Niclas Hedhman a écrit :
>>
>>> The full format would have been;
>>>
>>> Composition Problems Report:
>>> message: No implementation found for method
>>> method: java.util.Map<java.lang.String, java.lang.Integer>
>>> doAnotherThing(String name, int value)
>>> types: [Person,ValueComposite]
>>>
>>> (i.e. toString on a ParameterizedType) which I find quite annoying.
>>> Seldom
>>> enough the package name should be needed.
>>>
>>
>> Ok. I was thinking about our Classes.simpleGenericNameOf(Type type)
>> utility method that should make it easy to get:
>>
>> Composition Problems Report:
>> message: No implementation found for method
>> method: Map<String, Integer> doAnotherThing(String name, int value)
>> types: [Person,ValueComposite]
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Don't throw Exceptions during Bootstrap
Posted by Niclas Hedhman <ni...@hedhman.org>.
Right, but I am still not sure clarity increases, since generic types
variants can't override each other there is no ambiguity. I think I want to
keep the types without package names and without generic type information.
On Mon, Apr 3, 2017 at 2:09 AM, Paul Merlin <pa...@apache.org> wrote:
> Le 2017-03-31 05:02, Niclas Hedhman a écrit :
>
>> The full format would have been;
>>
>> Composition Problems Report:
>> message: No implementation found for method
>> method: java.util.Map<java.lang.String, java.lang.Integer>
>> doAnotherThing(String name, int value)
>> types: [Person,ValueComposite]
>>
>> (i.e. toString on a ParameterizedType) which I find quite annoying. Seldom
>> enough the package name should be needed.
>>
>
> Ok. I was thinking about our Classes.simpleGenericNameOf(Type type)
> utility method that should make it easy to get:
>
> Composition Problems Report:
> message: No implementation found for method
> method: Map<String, Integer> doAnotherThing(String name, int value)
> types: [Person,ValueComposite]
>
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Don't throw Exceptions during Bootstrap
Posted by Paul Merlin <pa...@apache.org>.
Le 2017-03-31 05:02, Niclas Hedhman a �crit�:
> The full format would have been;
>
> Composition Problems Report:
> message: No implementation found for method
> method: java.util.Map<java.lang.String, java.lang.Integer>
> doAnotherThing(String name, int value)
> types: [Person,ValueComposite]
>
> (i.e. toString on a ParameterizedType) which I find quite annoying.
> Seldom
> enough the package name should be needed.
Ok. I was thinking about our Classes.simpleGenericNameOf(Type type)
utility method that should make it easy to get:
Composition Problems Report:
message: No implementation found for method
method: Map<String, Integer> doAnotherThing(String name, int value)
types: [Person,ValueComposite]
Re: Don't throw Exceptions during Bootstrap
Posted by Niclas Hedhman <ni...@hedhman.org>.
I have had some email problems the last few days and didn't get Paul's
response but look it up on the archives.
The full format would have been;
Composition Problems Report:
message: No implementation found for method
method: java.util.Map<java.lang.String, java.lang.Integer>
doAnotherThing(String name, int value)
types: [Person,ValueComposite]
(i.e. toString on a ParameterizedType) which I find quite annoying. Seldom
enough the package name should be needed.
Cheers
On Wed, Mar 29, 2017 at 7:13 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
> And if there is a bit more to the methods;
>
> Composition Problems Report:
> message: No implementation found for method
> method: Map doAnotherThing(String name, int value)
> types: [Person,ValueComposite]
> --
> message: No implementation found for method
> method: void doOneThing()
> types: [Person,ValueComposite]
> --
>
> I am sacrificing the generics information, as it becomes very verbose.
>
>
> On Wed, Mar 29, 2017 at 6:54 PM, Niclas Hedhman <ni...@hedhman.org>
> wrote:
>
>> Ok,I have gotten started on this.
>>
>> InvalidCompositeException is the main character involved, and there are
>> two major kinks involved. One is that it is somewhat difficult to continue
>> without weird exception following, and the other is how, when what is
>> actually thrown.
>>
>> So, for that latter part, I am basically checking after model is created
>> in Energy4Java to see if there was any problems (aggregated into
>> InvalidCompositeException) and if so, throw an AssemblyException from
>> there.
>>
>> For the former part, I think it is just a matter of getting these
>> problems and refining the handling when it happens. Important is to inspect
>> the InvalidCompositeException (modelReport()) when anything goes wrong. So,
>> in Energy4Java I do that, and for any exception, create a
>> AssemblyReportException with the attached modelReport() for any issue, so
>> one can both trace the original problems and figure out what needs to be
>> done to handle the broken model without further problems.
>>
>> I think it is rather important to make the report as readable as
>> possible, so the report for two missing method implementations (my first
>> testcase) would end up something like this.
>>
>> Composition Problems Report:
>> message: No implementation found for method
>> method: doAnotherThing()
>> types: [Person,ValueComposite]
>> --
>> message: No implementation found for method
>> method: doOneThing()
>> types: [Person,ValueComposite]
>> --
>>
>> I think short names provides better readability than the FQCN everywhere.
>>
>> I will try to clean this up and try to get it out in the next few hours,
>> in case anyone would like to try it out.
>>
>> WDYT?
>>
>> On Sat, Mar 25, 2017 at 8:24 PM, Paul Merlin <pa...@apache.org>
>> wrote:
>>
>>>
>>> +1000 to more insight on assembly/bootstrap failures!
>>>
>>> Sounds related to:
>>> - Improved reporting on invalid assembly models
>>> https://issues.apache.org/jira/browse/POLYGENE-48
>>> - Easily report full application assembly
>>> https://issues.apache.org/jira/browse/POLYGENE-49
>>>
>>> POLYGENE-49 is about being able to serialize an application model.
>>> But it doesn't address reporting on erroneous application models.
>>>
>>> About startup and laziness, yes, getting as most errors as soon as
>>> possible would be a win.
>>> It'd be interesting to measure the impact on startup time of removing
>>> that laziness, it may be reasonable.
>>>
>>>
>>>
>>>
>>>
>>> Le 2017-03-25 04:54, Niclas Hedhman a écrit :
>>>
>>>> Looking at this at the moment, and there is an "interesting" tradeoff,
>>>> that
>>>> we should probably discuss.
>>>>
>>>> A fair bit of deferred work is going on, i.e. delaying the work until
>>>> it is
>>>> needed, in case it is not needed, which will improve start up time
>>>> quite a
>>>> lot.
>>>>
>>>> The down-side is that the structural problem is not showing up until any
>>>> time later, possibly in production.
>>>>
>>>> I think we should remove this "lazy loading" of classes, and check
>>>> everything possible at boot time.
>>>>
>>>> WDAYT?
>>>>
>>>> Niclas
>>>>
>>>> On Fri, Mar 24, 2017 at 5:30 PM, Niclas Hedhman <ni...@hedhman.org>
>>>> wrote:
>>>>
>>>> Gang,
>>>>> I was just thinking;
>>>>>
>>>>> We want it to become more efficient to find the runtime problems. One
>>>>> of
>>>>> the major problems is that one gets an exception after exception the
>>>>> first
>>>>> time we try to get going with a new project or a new subsystem in an
>>>>> existing project. And this start->exception->edit->compile cycle is
>>>>> tedious and not fun.
>>>>>
>>>>> Suggestion;
>>>>> 1. Introduce a "bootstrapPhase" somewhere.
>>>>> 2. Enhance ConstructionException with exact details of everything
>>>>> going on.
>>>>> 3. Make the ConstructionException constructor private and introduce a
>>>>> public static method to be called.
>>>>> 4. If Application.mode() is development or test, and bootstrapPhase is
>>>>> true, then add the Exception to a ThreadLocal list, otherwise throw
>>>>> exception as previously.
>>>>> 5. Figure out when bootstrap phase is "over", check if there are any
>>>>> Excepitons in the list, if so, generate an elaborate, machine readable
>>>>> report (for tooling) and abort. Otherwise clear bootstrapPhase and
>>>>> continue
>>>>> as normal.
>>>>>
>>>>> I am not sure if all structural problems can be caught in one swoop or
>>>>> not, but I am sure it would be a big improvement. Also, there might be
>>>>> other Exceptions that should be involved in this as well.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Cheers
>>>>> --
>>>>> Niclas Hedhman, Software Developer
>>>>> http://polygene.apache.org <http://zest.apache.org> - New Energy for
>>>>> Java
>>>>>
>>>>>
>>>
>>>
>>
>>
>> --
>> Niclas Hedhman, Software Developer
>> http://polygene.apache.org - New Energy for Java
>>
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Don't throw Exceptions during Bootstrap
Posted by Paul Merlin <pa...@apache.org>.
Niclas Hedhman a �crit :
> And if there is a bit more to the methods;
>
> Composition Problems Report:
> message: No implementation found for method
> method: Map doAnotherThing(String name, int value)
> types: [Person,ValueComposite]
> --
> message: No implementation found for method
> method: void doOneThing()
> types: [Person,ValueComposite]
> --
That looks awesome!
+1 for using simple names
> I am sacrificing the generics information, as it becomes very verbose.
You mean displaying
Map doAnotherThing(String name, int value)
instead of e.g.:
Map<String, Integer> doAnotherThing(String name, int value)
?
I think we have the utility methods to do that quite easily. But yeah,
you can't have overloads whose sole difference is a method parameter
type generic parameterized type. And for method return types we don't
care either. So, ok to sacrifice the generics in the report!
Re: Don't throw Exceptions during Bootstrap
Posted by Niclas Hedhman <ni...@hedhman.org>.
And if there is a bit more to the methods;
Composition Problems Report:
message: No implementation found for method
method: Map doAnotherThing(String name, int value)
types: [Person,ValueComposite]
--
message: No implementation found for method
method: void doOneThing()
types: [Person,ValueComposite]
--
I am sacrificing the generics information, as it becomes very verbose.
On Wed, Mar 29, 2017 at 6:54 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Ok,I have gotten started on this.
>
> InvalidCompositeException is the main character involved, and there are
> two major kinks involved. One is that it is somewhat difficult to continue
> without weird exception following, and the other is how, when what is
> actually thrown.
>
> So, for that latter part, I am basically checking after model is created
> in Energy4Java to see if there was any problems (aggregated into
> InvalidCompositeException) and if so, throw an AssemblyException from
> there.
>
> For the former part, I think it is just a matter of getting these problems
> and refining the handling when it happens. Important is to inspect the
> InvalidCompositeException (modelReport()) when anything goes wrong. So, in
> Energy4Java I do that, and for any exception, create a
> AssemblyReportException with the attached modelReport() for any issue, so
> one can both trace the original problems and figure out what needs to be
> done to handle the broken model without further problems.
>
> I think it is rather important to make the report as readable as possible,
> so the report for two missing method implementations (my first testcase)
> would end up something like this.
>
> Composition Problems Report:
> message: No implementation found for method
> method: doAnotherThing()
> types: [Person,ValueComposite]
> --
> message: No implementation found for method
> method: doOneThing()
> types: [Person,ValueComposite]
> --
>
> I think short names provides better readability than the FQCN everywhere.
>
> I will try to clean this up and try to get it out in the next few hours,
> in case anyone would like to try it out.
>
> WDYT?
>
> On Sat, Mar 25, 2017 at 8:24 PM, Paul Merlin <pa...@apache.org>
> wrote:
>
>>
>> +1000 to more insight on assembly/bootstrap failures!
>>
>> Sounds related to:
>> - Improved reporting on invalid assembly models
>> https://issues.apache.org/jira/browse/POLYGENE-48
>> - Easily report full application assembly
>> https://issues.apache.org/jira/browse/POLYGENE-49
>>
>> POLYGENE-49 is about being able to serialize an application model.
>> But it doesn't address reporting on erroneous application models.
>>
>> About startup and laziness, yes, getting as most errors as soon as
>> possible would be a win.
>> It'd be interesting to measure the impact on startup time of removing
>> that laziness, it may be reasonable.
>>
>>
>>
>>
>>
>> Le 2017-03-25 04:54, Niclas Hedhman a écrit :
>>
>>> Looking at this at the moment, and there is an "interesting" tradeoff,
>>> that
>>> we should probably discuss.
>>>
>>> A fair bit of deferred work is going on, i.e. delaying the work until it
>>> is
>>> needed, in case it is not needed, which will improve start up time quite
>>> a
>>> lot.
>>>
>>> The down-side is that the structural problem is not showing up until any
>>> time later, possibly in production.
>>>
>>> I think we should remove this "lazy loading" of classes, and check
>>> everything possible at boot time.
>>>
>>> WDAYT?
>>>
>>> Niclas
>>>
>>> On Fri, Mar 24, 2017 at 5:30 PM, Niclas Hedhman <ni...@hedhman.org>
>>> wrote:
>>>
>>> Gang,
>>>> I was just thinking;
>>>>
>>>> We want it to become more efficient to find the runtime problems. One of
>>>> the major problems is that one gets an exception after exception the
>>>> first
>>>> time we try to get going with a new project or a new subsystem in an
>>>> existing project. And this start->exception->edit->compile cycle is
>>>> tedious and not fun.
>>>>
>>>> Suggestion;
>>>> 1. Introduce a "bootstrapPhase" somewhere.
>>>> 2. Enhance ConstructionException with exact details of everything going
>>>> on.
>>>> 3. Make the ConstructionException constructor private and introduce a
>>>> public static method to be called.
>>>> 4. If Application.mode() is development or test, and bootstrapPhase is
>>>> true, then add the Exception to a ThreadLocal list, otherwise throw
>>>> exception as previously.
>>>> 5. Figure out when bootstrap phase is "over", check if there are any
>>>> Excepitons in the list, if so, generate an elaborate, machine readable
>>>> report (for tooling) and abort. Otherwise clear bootstrapPhase and
>>>> continue
>>>> as normal.
>>>>
>>>> I am not sure if all structural problems can be caught in one swoop or
>>>> not, but I am sure it would be a big improvement. Also, there might be
>>>> other Exceptions that should be involved in this as well.
>>>>
>>>> WDYT?
>>>>
>>>> Cheers
>>>> --
>>>> Niclas Hedhman, Software Developer
>>>> http://polygene.apache.org <http://zest.apache.org> - New Energy for
>>>> Java
>>>>
>>>>
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Don't throw Exceptions during Bootstrap
Posted by Niclas Hedhman <ni...@hedhman.org>.
Ok,I have gotten started on this.
InvalidCompositeException is the main character involved, and there are two
major kinks involved. One is that it is somewhat difficult to continue
without weird exception following, and the other is how, when what is
actually thrown.
So, for that latter part, I am basically checking after model is created in
Energy4Java to see if there was any problems (aggregated into
InvalidCompositeException) and if so, throw an AssemblyException from
there.
For the former part, I think it is just a matter of getting these problems
and refining the handling when it happens. Important is to inspect the
InvalidCompositeException (modelReport()) when anything goes wrong. So, in
Energy4Java I do that, and for any exception, create a
AssemblyReportException with the attached modelReport() for any issue, so
one can both trace the original problems and figure out what needs to be
done to handle the broken model without further problems.
I think it is rather important to make the report as readable as possible,
so the report for two missing method implementations (my first testcase)
would end up something like this.
Composition Problems Report:
message: No implementation found for method
method: doAnotherThing()
types: [Person,ValueComposite]
--
message: No implementation found for method
method: doOneThing()
types: [Person,ValueComposite]
--
I think short names provides better readability than the FQCN everywhere.
I will try to clean this up and try to get it out in the next few hours, in
case anyone would like to try it out.
WDYT?
On Sat, Mar 25, 2017 at 8:24 PM, Paul Merlin <pa...@apache.org> wrote:
>
> +1000 to more insight on assembly/bootstrap failures!
>
> Sounds related to:
> - Improved reporting on invalid assembly models
> https://issues.apache.org/jira/browse/POLYGENE-48
> - Easily report full application assembly
> https://issues.apache.org/jira/browse/POLYGENE-49
>
> POLYGENE-49 is about being able to serialize an application model.
> But it doesn't address reporting on erroneous application models.
>
> About startup and laziness, yes, getting as most errors as soon as
> possible would be a win.
> It'd be interesting to measure the impact on startup time of removing that
> laziness, it may be reasonable.
>
>
>
>
>
> Le 2017-03-25 04:54, Niclas Hedhman a écrit :
>
>> Looking at this at the moment, and there is an "interesting" tradeoff,
>> that
>> we should probably discuss.
>>
>> A fair bit of deferred work is going on, i.e. delaying the work until it
>> is
>> needed, in case it is not needed, which will improve start up time quite a
>> lot.
>>
>> The down-side is that the structural problem is not showing up until any
>> time later, possibly in production.
>>
>> I think we should remove this "lazy loading" of classes, and check
>> everything possible at boot time.
>>
>> WDAYT?
>>
>> Niclas
>>
>> On Fri, Mar 24, 2017 at 5:30 PM, Niclas Hedhman <ni...@hedhman.org>
>> wrote:
>>
>> Gang,
>>> I was just thinking;
>>>
>>> We want it to become more efficient to find the runtime problems. One of
>>> the major problems is that one gets an exception after exception the
>>> first
>>> time we try to get going with a new project or a new subsystem in an
>>> existing project. And this start->exception->edit->compile cycle is
>>> tedious and not fun.
>>>
>>> Suggestion;
>>> 1. Introduce a "bootstrapPhase" somewhere.
>>> 2. Enhance ConstructionException with exact details of everything going
>>> on.
>>> 3. Make the ConstructionException constructor private and introduce a
>>> public static method to be called.
>>> 4. If Application.mode() is development or test, and bootstrapPhase is
>>> true, then add the Exception to a ThreadLocal list, otherwise throw
>>> exception as previously.
>>> 5. Figure out when bootstrap phase is "over", check if there are any
>>> Excepitons in the list, if so, generate an elaborate, machine readable
>>> report (for tooling) and abort. Otherwise clear bootstrapPhase and
>>> continue
>>> as normal.
>>>
>>> I am not sure if all structural problems can be caught in one swoop or
>>> not, but I am sure it would be a big improvement. Also, there might be
>>> other Exceptions that should be involved in this as well.
>>>
>>> WDYT?
>>>
>>> Cheers
>>> --
>>> Niclas Hedhman, Software Developer
>>> http://polygene.apache.org <http://zest.apache.org> - New Energy for
>>> Java
>>>
>>>
>
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Don't throw Exceptions during Bootstrap
Posted by Paul Merlin <pa...@apache.org>.
+1000 to more insight on assembly/bootstrap failures!
Sounds related to:
- Improved reporting on invalid assembly models
https://issues.apache.org/jira/browse/POLYGENE-48
- Easily report full application assembly
https://issues.apache.org/jira/browse/POLYGENE-49
POLYGENE-49 is about being able to serialize an application model.
But it doesn't address reporting on erroneous application models.
About startup and laziness, yes, getting as most errors as soon as
possible would be a win.
It'd be interesting to measure the impact on startup time of removing
that laziness, it may be reasonable.
Le 2017-03-25 04:54, Niclas Hedhman a �crit�:
> Looking at this at the moment, and there is an "interesting" tradeoff,
> that
> we should probably discuss.
>
> A fair bit of deferred work is going on, i.e. delaying the work until
> it is
> needed, in case it is not needed, which will improve start up time
> quite a
> lot.
>
> The down-side is that the structural problem is not showing up until
> any
> time later, possibly in production.
>
> I think we should remove this "lazy loading" of classes, and check
> everything possible at boot time.
>
> WDAYT?
>
> Niclas
>
> On Fri, Mar 24, 2017 at 5:30 PM, Niclas Hedhman <ni...@hedhman.org>
> wrote:
>
>> Gang,
>> I was just thinking;
>>
>> We want it to become more efficient to find the runtime problems. One
>> of
>> the major problems is that one gets an exception after exception the
>> first
>> time we try to get going with a new project or a new subsystem in an
>> existing project. And this start->exception->edit->compile cycle is
>> tedious and not fun.
>>
>> Suggestion;
>> 1. Introduce a "bootstrapPhase" somewhere.
>> 2. Enhance ConstructionException with exact details of everything
>> going on.
>> 3. Make the ConstructionException constructor private and introduce a
>> public static method to be called.
>> 4. If Application.mode() is development or test, and bootstrapPhase is
>> true, then add the Exception to a ThreadLocal list, otherwise throw
>> exception as previously.
>> 5. Figure out when bootstrap phase is "over", check if there are any
>> Excepitons in the list, if so, generate an elaborate, machine readable
>> report (for tooling) and abort. Otherwise clear bootstrapPhase and
>> continue
>> as normal.
>>
>> I am not sure if all structural problems can be caught in one swoop or
>> not, but I am sure it would be a big improvement. Also, there might be
>> other Exceptions that should be involved in this as well.
>>
>> WDYT?
>>
>> Cheers
>> --
>> Niclas Hedhman, Software Developer
>> http://polygene.apache.org <http://zest.apache.org> - New Energy for
>> Java
>>
Re: Don't throw Exceptions during Bootstrap
Posted by Niclas Hedhman <ni...@hedhman.org>.
Looking at this at the moment, and there is an "interesting" tradeoff, that
we should probably discuss.
A fair bit of deferred work is going on, i.e. delaying the work until it is
needed, in case it is not needed, which will improve start up time quite a
lot.
The down-side is that the structural problem is not showing up until any
time later, possibly in production.
I think we should remove this "lazy loading" of classes, and check
everything possible at boot time.
WDAYT?
Niclas
On Fri, Mar 24, 2017 at 5:30 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Gang,
> I was just thinking;
>
> We want it to become more efficient to find the runtime problems. One of
> the major problems is that one gets an exception after exception the first
> time we try to get going with a new project or a new subsystem in an
> existing project. And this start->exception->edit->compile cycle is
> tedious and not fun.
>
> Suggestion;
> 1. Introduce a "bootstrapPhase" somewhere.
> 2. Enhance ConstructionException with exact details of everything going on.
> 3. Make the ConstructionException constructor private and introduce a
> public static method to be called.
> 4. If Application.mode() is development or test, and bootstrapPhase is
> true, then add the Exception to a ThreadLocal list, otherwise throw
> exception as previously.
> 5. Figure out when bootstrap phase is "over", check if there are any
> Excepitons in the list, if so, generate an elaborate, machine readable
> report (for tooling) and abort. Otherwise clear bootstrapPhase and continue
> as normal.
>
> I am not sure if all structural problems can be caught in one swoop or
> not, but I am sure it would be a big improvement. Also, there might be
> other Exceptions that should be involved in this as well.
>
> WDYT?
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java