Issue Details (XML | Word | Printable)

Key: ADFEMG-141
Type: Bug Bug
Status: In Progress In Progress
Priority: Major Major
Assignee: duncanmills
Reporter: Jan Vervecken
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
adfemg

dynamic taskFlowId EL expression exception eaten

Created: 11/Jun/13 06:56 PM   Updated: 16/Aug/13 01:14 AM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Tags:
Participants: chriscmuir, duncanmills and Jan Vervecken


 Description  « Hide

hi

Using JDeveloper 11.1.2.3.0 a bounded task-flow can be dropped on a page as a "Dynamic Region",
which will typically result in a taskFlow executable binding with a taskFlowId EL expression referring to a method like

public TaskFlowId getDynamicTaskFlowId()
{
	return TaskFlowId.parse(fTaskFlowId);
}

Such getDynamicTaskFlowId() method can evolve in more complex code (where an exception can be thrown).
If such method would throw an exception, it seems to be eaten by the framework.

Please consider the example application created using JDeveloper 11.1.1.2.3.0
at http://www.consideringred.com/files/oracle/2013/DynamicTaskFlowIdExceptionApp-v0.01.zip

Its getDynamicTaskFlowId() method explicitly throws an exception by calling the getDynamicTaskFlowIdThrowingException() method.

public class TaskFlowManager
	implements Serializable
{
	private String fTaskFlowId = "/WEB-INF/btf/some-btf.xml#some-btf";

	public TaskFlowId getDynamicTaskFlowId()
	{
		// return TaskFlowId.parse(fTaskFlowId);
		return getDynamicTaskFlowIdThrowingException();
		// return getDynamicTaskFlowIdCatchingExceptionReturningNull();
	}

	public TaskFlowId getDynamicTaskFlowIdThrowingException()
	{
		throw new RuntimeException("unable to get dynamic TaskFlowId");
	}

	public TaskFlowId getDynamicTaskFlowIdCatchingExceptionReturningNull()
	{
		try
		{
			return getDynamicTaskFlowIdThrowingException();
		}
		catch(Exception ex)
		{
			return null;
		}
	}
}

Running the "trySomeBTF" view activity in the unbounded task-flow will result in an empty page.
Nothing about the exception is shown on the page.
Nothing about the exception is shown on the Log panel in JDeveloper.
So, the exception seems to be "eaten" by the framework.

Can the eaten exception behavour described above be reproduced?
Is the eaten exception behavour described above intended behaviour?

many thanks
Jan Vervecken



Jan Vervecken added a comment - 11/Jun/13 06:56 PM

fyi

In the example application
at http://www.consideringred.com/files/oracle/2013/DynamicTaskFlowIdExceptionApp-v0.01.zip

If you would update the getDynamicTaskFlowId() method to call getDynamicTaskFlowIdCatchingExceptionReturningNull() the Log panel in JDeveloper shows

<TASKFLOW_ID_EL_NULL> <${s_taskFlowManager.dynamicTaskFlowId}> data.dynamictaskflowidexceptionapp_view_trySomeBTFPageDef.dynamicRegion1

regards
Jan Vervecken


duncanmills added a comment - 12/Jun/13 08:56 AM

Thanks for the testcase Jan. I'll log a bug on this. In the short term the obvious thing to do is to
1) log the error at the fatal level
2) Return either a null taskflowid so that the parent page can continue to render, or if you want to be more obvious, return the id of an "error" taskflow which can pick up and display your own error cause text from the session and display that in a way that will be directly visible to the user / developer.


duncanmills added a comment - 12/Jun/13 09:16 AM

Bug 16944352 - EXCEPTIONS RAISED BY TASKFLOW BINDING EVALUATION SWALLOWED BY UIXREGION created and published.
I have logged this as low priority (rather than major) because the developer already has all the power they need to correctly report their own exception and does not need to wait for the framework to handle this specific scenario.


Jan Vervecken added a comment - 12/Jun/13 05:43 PM

Thank you for the updates Duncan.

  • about "... the obvious thing to do is to ... 2) Return either a null taskflowid so that the parent page can continue to render, ..."
    • If I do return null, e.g. by calling getDynamicTaskFlowIdCatchingExceptionReturningNull(), the page remains completely blank (while it does have a af:panelHeader component which could be expected to "continue to render").
      So, I am not sure I understand this workaround to return "a null taskflowid", or I don't understand what to expect from "the parent page can continue to render", or this is not intended behaviour, or something else.
  • about "Bug 16944352 - EXCEPTIONS RAISED BY TASKFLOW BINDING EVALUATION SWALLOWED BY UIXREGION created and published."
    • I will have a look when possible, "My Oracle Support is currently experiencing an unscheduled outage.".

regards
Jan Vervecken


duncanmills added a comment - 12/Jun/13 06:43 PM

To be clear - tweak your getDynamicTaskFlowId method to return String rather than TaskFlowId, then in the case of an exception return ""; The framework will then automatically use an empty taskflow and the the rest of the page will render.
Or you could maintain your own "error reporting" taskflow and return it's ID / name instead


Jan Vervecken added a comment - 12/Jun/13 08:08 PM

Thanks for your reply Duncan.

  • about "... tweak your getDynamicTaskFlowId method to return String rather than TaskFlowId ..."
    • Thanks for pointing out that a String can be returned instead of a TaskFlowId. Where has that been documented?
      The IDE itself creates a method returning a TaskFlowId when a bounded task-flow is dropped as a "Dynamic Region".
  • about "... in the case of an exception return ""; The framework will then automatically use an empty taskflow and the the rest of the page will render. ..."
  • about "Bug 16944352 - EXCEPTIONS RAISED BY TASKFLOW BINDING EVALUATION SWALLOWED BY UIXREGION created and published."
    On My Oracle Support I have been able to find bug 16944352, "EXCEPTIONS RAISED BY TASKFLOW BINDING EVALUATION SWALLOWED BY UIXREGION".
    Thanks for mentioning "Reported Via ADF EMG issue: 141" in a published comment.
  • about bug 16944352 mentioning "This problem is moot if the developer follows good practice and logs their own errors correctly"
    • Is this suggesting that it is "good practice" for all application/custom methods called by the framework to always catch and handle every possible Throwable, just in case that the framework might "swallow" such Throwables.
      Or does this "good practice" only apply as a workaround for known framework bugs?

regards
Jan Vervecken


chriscmuir added a comment - 15/Jul/13 01:27 AM

Sent developer email prompting query on progress as it missed its FixBy release number, waiting on response.

CM.


chriscmuir added a comment - 16/Aug/13 01:14 AM

Bug updated to FixBy 12.1.4.

CM.