Re: What is passed between processes?

Like with any programming language, some errors can be detected in a 
process statically or dynamically. Examples of static errors can include 
incorrect syntax, missing components, etc. Examples of dynamic errors 
include failed execution of an XSLT stylesheet, error reading a URL, etc.

So in general, there are reasons to support both static and dynamic 
error handling.

Now in the case of missing components, a case can be made both ways: 
static detection of missing components is useful because it brings more 
robustness to your code (like static typing in Java vs. runtime typing 
in Javascript). However, in particular if you have conditional or lazy 
processing, some steps in your process may not run at all, in which case 
it would make sense to report an error only at runtime, as the process 
may well be able to complete without errors.

-Erik

Rui Lopes wrote:
> But should this error handling mechanism be run as a pre-processing step 
> or should we allow to run all processing steps until finding an 
> unsupported processing component? I'm not sure if there's a benefit in 
> executing partially a pipeline.
> 
> Rui
> 
> Erik Bruchez wrote:
> 
>>
>> Fang, Andrew wrote:
>>
>>> I was actually thinking about a fall back mechanism here. Custom
>>> component should specify a fallback that must be implemented by all
>>> pipeline implementations. It could be as simple as passing the
>>> information along without any processing.
>>
>>
>>
>> I wonder how many use cases would actually benefit from this. I would 
>> think that in most situations you would simply be in a "fatal error" 
>> type of scenario. Consider simply an XSLT transformation you want to 
>> perform: if you don't have an XSLT transformation component available, 
>> your task simply cannot be executed. What sense does it make to pass 
>> the information unmodified?
>>
>> Maybe the right way of looking at this suggestion is for its 
>> proponents to provide concrete use cases that would benefit from a 
>> fallback mechanism.
>>
>> Alternatively, a generic error (exception) handling mechanism could 
>> take care of the issue, assuming the absence of a component is handled 
>> as a runtime error.
>>
>> -Erik

Received on Wednesday, 11 January 2006 15:58:03 UTC