Hello @banrisulssw!
Thanks for the test case! This really looks strange, any response written after
Server.ClearError() is replaced by
{} no matter what.
What I could make out of the test case you provided for proper error handling and taking advantage of the
Page_Error() server-side event was this:
<%@ Page Language="C#" %>
<!DOCTYPE html>
<script runat="server">
protected void Test_ButtonOnDirectClick(object sender, DirectEventArgs e)
{
throw new Exception("My Exception");
}
public void Page_Error(object sender, EventArgs e)
{
Exception exc = Server.GetLastError();
Server.ClearError();
Response.StatusCode = 500;
Response.StatusDescription = "Exception detected. Message: " + exc.Message;
}
</script>
<html>
<head id="Head1" runat="server">
<title>Default Exception Handling</title>
</head>
<body>
<form id="Form1" runat="server">
<h1>Default Button</h1>
<ext:ResourceManager ID="ResourceManager1" runat="server">
<Listeners>
<AjaxRequestException Handler="Ext.Msg.alert('Server Error', 'error: ' + result.errorMessage); return false;" />
</Listeners>
</ext:ResourceManager>
<ext:Container ID="Container1"
runat="server"
Layout="VBoxLayout"
Height="650">
<Items>
<ext:Button ID="btnSalvar"
runat="server"
Width="100"
Height="100"
Text="test"
Icon="Disk"
>
<DirectEvents>
<Click OnEvent="Test_ButtonOnDirectClick" />
</DirectEvents>
</ext:Button>
</Items>
</ext:Container>
</form>
</body>
</html>
Some considerations about the code above:
- Code behind is merged in ASPX code (it is the same, just shorter for test cases and makes it namespace-indepentent)
- Added a listener to the Ext.NET ResourceManager to handle generic AJAX Errors (that is the usual way to handle errors from AJAX).
- I could just let the
Page_Error() run without
Server.ClearErrors() and handle the error message client-side, but it sends that whole error page that would be complex to interpret and trim the desired information
- The
AjaxRequestException event handler returns
false so that the button's default request failure handler is not called (will force a window with the message).
- I set the page error back to 500 after I clear errors on it and set up the message in the status description field, this way I can pass server-side tailored message to the resource manager's error handler to display to the user.
I hope this alternative works well for you, but there's an odd problem here that is replacing the whole response by an empty javascritp/json object representation (the string
{}
).
We have logged this issue with
Page_Error() under
#1427 and we will update here as soon as we fix the problem. It may be the case this is not a bug, but a limitation or a never planned (until now) feature. For now we logged it as a bug but it may change as we get in-depth with the issue.
I hope this helps!