polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Don't throw Exceptions during Bootstrap
Date Wed, 29 Mar 2017 11:13:02 GMT
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 <niclas@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 <paulmerlin@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 <niclas@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message