I am using Janus(Third Party) Grid and getting the "System.StackOverflowException". Don't know how to solve it. I would like to appreciate for any help.
private void gridEX1_FormattingRow(object sender, RowLoadEventArgs e)
{
int index = e.Row.RowIndex;
try
{
if (!Convert.IsDBNull(gridEX1.GetRow(index).Cells["HEADER_ORDER_PACKAGE_ROW_ID"].Value))
{
if (Convert.ToInt32(gridEX1.GetRow(index).Cells["HEADER_ORDER_PACKAGE_ROW_ID"].Value) == PARENT_ORDER_PACKAGE_ID)
{
**gridEX1.MoveToRowIndex(index);**
GridEXRow curRow = gridEX1.GetRow();
if (curRow != null)
{
curRow.Expanded = true;
}
}
}
}
catch (Exception ex)
{
}
}
It seems that one of the lines inside your handler invoke the handler itself again. And so on, so you get StackOverflow.
Related
Summary:
My GraphQL ExecuteAsync returns a result that contains. According to the stackTrace provided below, the system cannot resolve my custom type remitsGeneralSearch. The remitsGeneralSearch resolver can return a type called ClaimPaymentOrCheckSearchGraphType which is a UnionGraphType.
StackTrace:
["GraphQL.ExecutionError: Error trying to resolve remitsGeneralSearch.\n ---> System.InvalidOperationException: Unexpected type: \n at GraphQL.Execution.ExecutionStrategy.BuildExecutionNode(ExecutionNode parent, IGraphType graphType, Field field, FieldType fieldDefinition, String[] path)\n at GraphQL.Execution.ExecutionStrategy.SetSubFieldNodes(ExecutionContext context, ObjectExecutionNode parent, Dictionary`2 fields)\n at GraphQL.Execution.ExecutionStrategy.SetSubFieldNodes(ExecutionContext context, ObjectExecutionNode parent)\n at GraphQL.Execution.ExecutionStrategy.ExecuteNodeAsync(ExecutionContext context, ExecutionNode node)\n --- End of inner exception stack trace ---"]4008305)
GraphQL Version: 2.4.0
FrameWork: .Net
OS: MacOS Catalina
Links Referenced: https://github.com/graphql-dotnet/graphql-dotnet/issues/964
CODE SNIPPETS:
RESOLVER:
FieldAsync<ClaimPaymentOrCheckSearchGraphType>(
"remitsGeneralSearch",
resolve: async context =>
{
var securityFilter = await GetUserRemitFilters(context);
var range = context.GetRange();
var sortFields = context.GetArgument<List<SortField>>("sort") ?? Enumerable.Empty<SortField>();
var whereClaimPayment = context.GetArgument<ClaimPaymentSearchFilter>("whereClaimPayment");
Connection<ClaimPaymentSearchRow> claimPaymentSearchRowResult;
try
{
using (LogContext.PushProperty("where", whereClaimPayment, true))
{
//claimPaymentSearchRowResult = await DMAQueryService.GetRemitReadersAsync(context);
var whereArguments = context.Arguments["whereClaimPayment"] as Dictionary<string, object>;
claimPaymentSearchRowResult = await DMAQueryService.GetRemitReadersAsync(
range,
whereClaimPayment,
whereArguments,
sortFields,
securityFilter,
context.CancellationToken
);
}
}
catch (Exception e)
{
_logger.LogInformation("Exception occurred {e}", e);
throw e;
}
var userRemitFilters = context.UserContext as Services.DMA.UserRemitFilters;
if (claimPaymentSearchRowResult.EdgeCount > 0)
{
return claimPaymentSearchRowResult;
}
var _whereCheckSearch = context.GetArgument<CheckSearchFilter>("whereCheck");
try
{
Connection<CheckSearchRow> checkSearchRowResult;
using (LogContext.PushProperty("whereCheck", _whereCheckSearch, true))
{
checkSearchRowResult = await DMAQueryService.GetCheckReadersAsync(context);
return checkSearchRowResult;
}
}
catch (Exception e)
{
throw e;
}
},arguments: queryArguments
);
}
catch (Exception e)
{
throw e;
}
Custom GraphType:
[Transient]
public class ClaimPaymentOrCheckSearchGraphType : UnionGraphType
{
private readonly ILogger<ClaimPaymentOrCheckSearchGraphType> _logger;
public ClaimPaymentOrCheckSearchGraphType(
ILogger<ClaimPaymentOrCheckSearchGraphType> logger,
ConnectionGraphType<ClaimPaymentSearchGraphType> claimPaymentSearchGraphType,
ConnectionGraphType<CheckSearchGraphType> checkSearchGraphType
)
{
_logger = logger;
Type<ConnectionGraphType<ClaimPaymentSearchGraphType>>();
Type<ConnectionGraphType<CheckSearchGraphType>>();
ResolveType = obj =>
{
try
{
if (obj is Connection<ClaimPaymentSearchRow>)
{
return claimPaymentSearchGraphType;
}
if (obj is Connection<CheckSearchRow>)
{
return checkSearchGraphType;
}
throw new ArgumentOutOfRangeException($"Could not resolve graph type for {obj.GetType().Name}");
}
catch (Exception e)
{
_logger.LogInformation("ClaimPaymentOrCheckSearchGraphType Exception {e}: ", e);
throw e;
}
};
}
}
Link to answer found here: https://github.com/graphql-dotnet/graphql-dotnet/issues/2674Try replacing this:
Type<ConnectionGraphType<ClaimPaymentSearchGraphType>>();
Type<ConnectionGraphType<CheckSearchGraphType>>();
with this:
AddPossibleType(claimPaymentSearchGraphType);
AddPossibleType(checkSearchGraphType);
I'm thinking that if you're registering these types as transients, then the copy that gets registered to the schema initialization code is a different copy that gets returned from ResolveType. Because of that, its fields' ResolvedType properties was never set, and so null is passed into BuildExecutionNode for the graphType instead of a resolved type.
If the ResolveType method could return a type rather than an instance, there wouldn't be an issue, but unfortunately that's not the way it works. Or you could register the type as a singleton.
Looking at the code I recently wrote made me wonder:
public void process(Deque<OperandToken> stack, EvaluationConfig context) {
OperandToken a;
OperandToken b;
try {
b = stack.pop();
a = stack.pop();
} catch (NoSuchElementException e) {
throw new EvaluationException("Syntax error: not enough operands");
}
if (!a.isValueTypeOf(Number.class) || !b.isValueTypeOf(Number.class)) {
throw new EvaluationException("Syntax error...");
}
// more actions on a and b and finally stack.push(result)
}
Same but with catch in the end:
public void process(Deque<OperandToken> stack, EvaluationConfig context) {
try {
OperandToken b = stack.pop();
OperandToken a = stack.pop();
if (!a.isValueTypeOf(Number.class) || !b.isValueTypeOf(Number.class)) {
throw new EvaluationException("Syntax error...");
}
// more actions on a and b and finally stack.push(result)
} catch (NoSuchElementException e) {
throw new EvaluationException("Syntax error: not enough operands");
}
}
Is there any rule about preferred method, or some arguments (e.g. performance) that the first / the second style should be used? In both cases NoSuchElementException is the only exception that can appear, but the question is also valid for cases when there are multiple exceptions that can be thrown on different lines.
Hello I have no idea where I should start looking. I add few prop (before that my code run fine), then I get
System.Diagnostics.Debugger.Break();
so then I comment that changes, but that didn't help.
Could you suggest me where I should start looking for solution?
MyCode:
namespace SkydriveContent
{
public partial class MainPage : PhoneApplicationPage
{
private LiveConnectClient client;
FilesManager fileManager = new FilesManager();
// Constructor
public MainPage()
{
InitializeComponent();
}
private void signInButton1_SessionChanged(object sender, LiveConnectSessionChangedEventArgs e)
{
if (e.Status == LiveConnectSessionStatus.Connected)
{
client = new LiveConnectClient(e.Session);
infoTextBlock.Text = "Signed in.";
client.GetCompleted +=
new EventHandler<LiveOperationCompletedEventArgs>(OnGetCompleted);
client.GetAsync("/me/skydrive/files/");
fileManager.CurrentFolderId = "/me/skydrive/files/";
}
else
{
infoTextBlock.Text = "Not signed in.";
client = null;
}
}
void OnGetCompleted(object sender, LiveOperationCompletedEventArgs e)
{
//Gdy uda nam się podłaczyc do konta skydrive
if (e.Error == null)
{
signInButton1.Visibility = System.Windows.Visibility.Collapsed;
infoTextBlock.Text = "Hello, signed-in user!";
List<object> data = (List<object>)e.Result["data"];
fileManager.FilesNames.Clear();
filemanager.filesnames.add("..");
foreach (IDictionary<string,object> item in data)
{
File file = new File();
file.fName = item["name"].ToString();
file.Type = item["type"].ToString();
file.Url = item["link"].ToString();
file.ParentId = item["parent_id"].ToString();
file.Id = item["id"].ToString();
fileManager.Files.Add(file);
fileManager.FilesNames.Add(file.fName);
}
FileList.ItemsSource = fileManager.FilesNames;
}
else
{
infoTextBlock.Text = "Error calling API: " +
e.Error.ToString();
}
}
private void FileList_Tap(object sender, GestureEventArgs e)
{
foreach (File item in fileManager.Files)
{
if (item.fName == FileList.SelectedItem.ToString() )
{
switch (item.Type)
{
case "file":
MessageBox.Show("Still in progress");
break;
case "folder":
fileManager.CurrentFolderId = item.ParentId.ToString();
client.GetAsync(item.Id.ToString() + "/files");
break;
default:
MessageBox.Show("Coś nie działa");
break;
}
}
else if (FileList.SelectedItem.ToString() == "..")
{
client.GetAsync(fileManager.CurrentFolderId + "/files");
}
}
}
}
}
Running stop at that line.
// Code to execute if a navigation fails
private void RootFrame_NavigationFailed(object sender, NavigationFailedEventArgs e)
{
if (System.Diagnostics.Debugger.IsAttached)
{
// A navigation has failed; break into the debugger
System.Diagnostics.Debugger.Break();
}
}
You should check all of the URLs you have both in the XAML and code. When you get to the NavigationFailed function, it means that the phone tried to navigate to some page that did not existed. We would be able to help more if you could tell what were you doing when the app threw the exception.
System.Diagnostics.Debugger.Break();
usually happens because of an Uncaught Exception.
Either post the code which started giving problems, or the stack trace when you encounter this problem.
No one can tell anything without actually seeing what you are doing.
Here's a piece of code we've all written:
public CustomerTO getCustomerByCustDel(final String cust, final int del)
throws SQLException {
final PreparedStatement query = getFetchByCustDel();
ResultSet records = null;
try {
query.setString(1, cust);
query.setInt(2, del);
records = query.executeQuery();
return this.getCustomer(records);
} finally {
if (records != null) {
records.close();
}
query.close();
}
}
If you omit the 'finally' block, then you leave database resources dangling, which obviously is a potential problem. However, if you do what I've done here - set the ResultSet to null outside the **try** block, and then set it to the desired value inside the block - PMD reports a 'DD anomaly'. In the documentation, a DD anomaly is described as follows:
DataflowAnomalyAnalysis: The dataflow analysis tracks local definitions, undefinitions and references to variables on different paths on the data flow.From those informations there can be found various problems. [...] DD - Anomaly: A recently defined variable is redefined. This is ominous but don't have to be a bug.
If you declare the ResultSet outside the block without setting a value, you rightly get a 'variable might not have been initialised' error when you do the if (records != null) test.
Now, in my opinion my use here isn't a bug. But is there a way of rewriting cleanly which would not trigger the PMD warning? I don't particularly want to disable PMD's DataFlowAnomalyAnalysis rule, as identifying UR and DU anomalies would be actually useful; but these DD anomalies make me suspect I could be doing something better - and, if there's no better way of doing this, they amount to clutter (and I should perhaps look at whether I can rewrite the PMD rule)
I think this is clearer:
PreparedStatement query = getFetchByCustDel();
try {
query.setString(1, cust);
query.setInt(2, del);
ResultSet records = query.executeQuery();
try {
return this.getCustomer(records);
} finally {
records.close();
}
} finally {
query.close();
}
Also, in your version the query doesn't get closed if records.close() throws an exception.
I think that DD anomaly note is more bug, than a feature
Also, the way you free resources is a bit incomplete, for example
PreparedStatement pstmt = null;
Statement st = null;
try {
...
} catch (final Exception e) {
...
} finally {
try{
if (pstmt != null) {
pstmt.close();
}
} catch (final Exception e) {
e.printStackTrace(System.err);
} finally {
try {
if (st != null) {
st.close();
}
} catch (final Exception e) {
e.printStackTrace(System.err);
}
}
}
moreover this is not right again, cuz you should close resources like that
PreparedStatement pstmt = null;
Throwable th = null;
try {
...
} catch (final Throwable e) {
<something here>
th = e;
throw e;
} finally {
if (th == null) {
pstmt.close();
} else {
try {
if (pstmt != null) {
pstmt.close();
}
} catch (Throwable u) {
}
}
}
I've got this...
public void FooAsync()
{
AsyncManager.OutstandingOperations.Increment();
Task.Factory.StartNew(() =>
{
try
{
doSomething.Start();
}
catch (Exception e)
{
AsyncManager.Parameters["exc"] = e;
}
finally
{
AsyncManager.OutstandingOperations.Decrement();
}
});
}
public ActionResult FooCompleted(Exception exc)
{
if (exc != null)
{
throw exc;
}
return View();
}
Is there a better way of passing an exception back to ASP.net?
Cheers, Ian.
Task will catch the exceptions for you. If you call task.Wait(), it will wrap any caught exceptions in an AggregateException and throw it.
[HandleError]
public void FooAsync()
{
AsyncManager.OutstandingOperations.Increment();
AsyncManager.Parameters["task"] = Task.Factory.StartNew(() =>
{
try
{
DoSomething();
}
// no "catch" block. "Task" takes care of this for us.
finally
{
AsyncManager.OutstandingOperations.Decrement();
}
});
}
public ActionResult FooCompleted(Task task)
{
// Exception will be re-thrown here...
task.Wait();
return View();
}
Simply adding a [HandleError] attribute isn't good enough. Since the exception occurs in a different thread, we have to get the exception back to the ASP.NET thread in order to do anything with it. Only after we have the exception thrown from the right place will the [HandleError] attribute be able to do its job.
Try putting an attribute like this in FooAsync action:
[HandleError (ExceptionType = typeof (MyExceptionType) View = "Exceptions/MyViewException")]
This way you can create a view to display the detailed error to the user.