I'm integrating Flurry Analytics into my Xamarin/MonoTouch iOS App with the following binding:
https://github.com/mono/monotouch-bindings/tree/master/FlurryAnalytics
Now, I'd like to use Flurry Analytic's error logging:
void LogError (string errorID, string message, NSException exception);
I'm catching exceptions with this code in my AppDelegate:
AppDomain.CurrentDomain.UnhandledException += (object sender, UnhandledExceptionEventArgs e) => { /**/ };
However, as far as I can figure out Xamarin/MonoTouch has converted all NSExceptions to System.Exception.
Can System.Exception be converted back to NSException so I can use it in the LogError routine?
Or is it possible to catch NSExceptions in a Xamarin/MonoTouch project?
Why not use the UncaughtExceptionHandler in the AppDelegate class? They have a sample on the github page you mentioned.
static void UncaughtExceptionHandler(IntPtr handle)
{
var exception = new NSException(handle);
FA.Flurry.LogError("3584", exception.Reason, exception);
Console.WriteLine(#"Got an exception...{0} -- {1}", exception.Name, exception.Reason);
}
https://github.com/mono/monotouch-bindings/blob/master/FlurryAnalytics/sample/Xamarin.FlurryAnalyticsSample/AppDelegate.cs
Edit:
The sample also shows how to log a System.Exception in the AnalyticsViewController.cs
Related
I have followed the steps in the following website.
https://github.com/NLog/NLog/wiki/Getting-started-with-ASP.NET-Core-3
However, when I run my project, the following error has been displayed.
System.Exception: 'Could not resolve a service of type 'Microsoft.Extensions.Logging.ILoggingBuilder' for the parameter 'logger' of method 'Configure' on type 'myProj.Startup'.'
The code stopped at the following point throw. . I have tried to google it but it seems that there is no similar issue. I wish someone could help. Thanks!
public static void Main(string[] args)
{
var logger = NLog.Web.NLogBuilder.ConfigureNLog("nlog.config").GetCurrentClassLogger();
try
{
logger.Debug("init main");
CreateHostBuilder(args).Build().Run();
}
catch (Exception exception)
{
//NLog: catch setup errors
logger.Error(exception, "Stopped program because of exception");
*throw;*
}
finally
{
I want to get the specific error message of ANTLR4's parser.
And I found that there are two way to handle error: errorListener and errorHandler.
// set error handler
parser.removeErrorListeners();
parser.addErrorListener(new QueryErrorListener());
parser.setErrorHandler(new BailErrorStrategy());
But I'm confused about the difference between them.
I found that, errorListener can get the specific error message, but it can only print it or log it, can't throw a exception.
The implemention of errorListener as bellow:
public class QueryErrorListener extends BaseErrorListener {
private static final Logger LOGGER = LoggerFactory.getLogger(QueryDispatcher.class);
#Override
public void syntaxError(Recognizer<?, ?> recognizer, Object offendingSymbol,
int line, int charPositionInLine, String msg,
RecognitionException e)
{
List<String> stack = ((Parser)recognizer).getRuleInvocationStack(); Collections.reverse(stack);
String errorMessage = "line "+line+":"+charPositionInLine+" at "+
offendingSymbol+": "+msg;
LOGGER.error("rule stack: "+stack);
LOGGER.error(errorMessage);
QueryParseErrorStrategy queryParseErrorStrategy = new QueryParseErrorStrategy();
}
}
At the same time, the errorHandler can only throw a exception ParseCancellationException without any specific message.
public class BailErrorStrategy extends DefaultErrorStrategy {
/** Instead of recovering from exception {#code e}, re-throw it wrapped
* in a {#link ParseCancellationException} so it is not caught by the
* rule function catches. Use {#link Exception#getCause()} to get the
* original {#link RecognitionException}.
*/
#Override
public void recover(Parser recognizer, RecognitionException e) {
for (ParserRuleContext context = recognizer.getContext(); context != null; context = context.getParent()) {
context.exception = e;
}
throw new ParseCancellationException(e);
}
/** Make sure we don't attempt to recover inline; if the parser
* successfully recovers, it won't throw an exception.
*/
#Override
public Token recoverInline(Parser recognizer)
throws RecognitionException
{
InputMismatchException e = new InputMismatchException(recognizer);
for (ParserRuleContext context = recognizer.getContext(); context != null; context = context.getParent()) {
context.exception = e;
}
throw new ParseCancellationException(e);
}
/** Make sure we don't attempt to recover from problems in subrules. */
#Override
public void sync(Parser recognizer) { }
}
I've try to find a solution, add a transfer method to get detail message from ParseCancellationException, as bellow.
I found that I can get some message from a Token object of RecognitionException, but I can only find the line/charPositionInLine/offendingSymbol message, I don't know where is the detail message, like "missing 'xxx', expect 'yyy'"
public class ANTLRExceptionTransfer {
public static SemanticException transfer(RecognitionException re) {
String errorMsg = "";
Recognizer<?, ?> recognizer = re.getRecognizer();
Token offendingSymbol = re.getOffendingToken();
int line = offendingSymbol.getLine();
int charPositionInLine = offendingSymbol.getCharPositionInLine();
// ????????
String msg = "";
List<String> stack = ((Parser)recognizer).getRuleInvocationStack();
Collections.reverse(stack);
String errorMessage = "rule stack: "+stack;
errorMessage = "\nline "+line+":"+charPositionInLine+" at "+
offendingSymbol+": "+msg;
return new SemanticException(errorMessage);
}
}
Is it the right way to use errorHandler?
How can I get a exception with specific error message?
I find the setErrorHandler name a bit confusing. It should be consistent with what you can set there. It's for setting an error strategy (which is of course also some kind of handling...).
Both error listener and error strategy are means for the application to deal with parse errors. The error listener gets called for each encountered error and allows the application to collect them (e.g. to show them in a GUI). You'll get a pre-generated error message or can create an own one from the passed in parameters.
The error strategy is a class that determines how to continue after an error was found. The default stategy is to try to sync to the input stream and continue with parsing. Sometimes however you want the parser to stop immediately and avoid lengthy operations after an error was found. This so-called bail-out strategy is another class in ANTLR4, usually used for SLL parsing. See one of my projects for how that's used.
The thrown ParseCancellationException in the bail-out error strategy is an exception without any additional info. It's not meant for error handling (in the sense of sending it to the application/user, you have the error handler for that), but instead to throw an exception that's not one of the usual parser exceptions, in order to bypass all error catching and find a way out of the ongoing parse run as quick as possible. You have to catch this exception in your own code or it will bubble up to the root context of your application (and might cause the application to quit, depending on the target language).
I'm uising web api 2 to develop services for a client, to manage errors we are using a ExceptionsFilterAttribute, but as you know, in this level not all exception are catched.
Some errors are raised in protected void Application_AuthenticateRequest(Object sender, EventArgs e) and I want to handle them and send a custom message to our client to give him more details about the error, to solve this I create a GlobalExceptionHandler
public class GlobalExceptionHandler: ExceptionHandler
{
//A basic DTO to return back to the caller with data about the error
private class ErrorInformation
{
public string Message { get; set; }
public DateTime ErrorDate { get; set; }
}
public override void Handle(ExceptionHandlerContext context)
{
//Return a DTO representing what happened
context.Result = new ResponseMessageResult(context.Request.CreateResponse(HttpStatusCode.InternalServerError,
new ErrorInformation { Message="We apologize but an unexpected error occured. Please try again later.", ErrorDate=DateTime.UtcNow }));
//This is commented out, but could also serve the purpose if you wanted to only return some text directly, rather than JSON that the front end will bind to.
//context.Result = new ResponseMessageResult(context.Request.CreateResponse(HttpStatusCode.InternalServerError, "We apologize but an unexpected error occured. Please try again later."));
}
}
In WebApiConfig i added this line :
config.Services.Replace(typeof(IExceptionHandler), new GlobalExceptionHandler());
The the Application_AuthenticateRequest raise some errors but GlobalExceptionHandler is never reached.
Do you have any idea how can I solve this issue ?
Thanks in advance.
Application_AuthenticateRequest does not come in the Web API pipeline. So if an exception is thrown in this method those can be caught by the Web API exception handler, because the exception is thrown before the Web API pipeline is started.
There are two ways to do this:
Either change the authentication mechanism and use Web API Authentication(IAuthenticationFilter) instead of Application_AuthenticateRequest.
If this project has only Web API related controllers, not like MVC and all.
Or use Application_Error in the Global.asax.cs file to catch the exception thrown in Application_AuthenticateRequest
I am looking to develop an error handling strategy for a SharePoint solution that makes use of sandboxed webparts. I was initially looking at a general exception handling approach based on this article, but this doesn't work for sandboxed webparts. Once an unhandled exception has been thrown in the sandbox, the user code service appears to take control, so that the exception handling in the base web part isn't reached. Are there any established error handling approaches for sandboxed solutions?
Is anyone aware of a method of determining when an unhandled exception has been thrown in a sandboxed webpart, if only to change the displayed error message to a more user friendly message? I would like to replace the standard "Web Part Error: Unhandled exception was thrown by the sandboxed code wrapper's Execute method in the partial trust app domain: An unexpected error has occurred." message at very least.
Thanks, MagicAndi.
Actually, you can follow the approach suggested by the article you mentioned. You just have to provide safe overridables for all virtual properties and methods your descendant web parts are going to override. The patter can be described:
Override and seal every virtual property and method supposed to be overriden with code that can throw an exception.
Create a virtual counterpart of the overridable with the same prototype and call the base class from it if necessary. This is supposed to be overriden by your descendants.
Call the new overridable from the sealed member in a try&catch and remember the exception if caught there.
Rendering method either renders the usual content or the remembered error message.
This is a torso of the base class I use:
public class ErrorSafeWebPart : WebPart {
#region Error remembering and rendering
public Exception Error { get; private set; }
// Can be used to skip some code later that needs not
// be performed if the web part renders just the error.
public bool HasFailed { get { return Error != null; } }
// Remembers just the first error; following errors are
// usually a consequence of the first one.
public void RememberError(Exception error) {
if (Error != null)
Error = error;
}
// You can do much better error rendering than this code...
protected virtual void RenderError(HtmlTextWriter writer) {
writer.WriteEncodedText(Error.ToString());
}
#endregion
#region Overriddables guarded against unhandled exceptions
// Descendant classes are supposed to override the new DoXxx
// methods instead of the original overridables They should
// not catch exceptions and leave it on this class.
protected override sealed void CreateChildControls() {
if (!HasFailed)
try {
DoCreateChildControls();
} catch (Exception exception) {
RememberError(exception);
}
}
protected virtual void DoCreateChildControls()
{}
protected override sealed void OnInit(EventArgs e) {
if (!HasFailed)
try {
DoOnInit(e);
} catch (Exception exception) {
RememberError(exception);
}
}
protected virtual void DoOnInit(EventArgs e) {
base.OnInit(e);
}
// Continue similarly with OnInit, OnLoad, OnPreRender, OnUnload
// and/or others that are usually overridden and should be guarded.
protected override sealed void RenderContents(HtmlTextWriter writer) {
// Try to render the normal contents if there was no error.
if (!HasFailed)
try {
DoRenderContents(writer);
} catch (Exception exception) {
RememberError(exception);
}
// If an error occurred in any phase render it now.
if (HasFailed)
RenderError(writer);
}
protected virtual void DoRenderContents(HtmlTextWriter writer) {
base.RenderContents(writer);
}
#endregion
}
--- Ferda
I developed a desktop application, it's almost done but still contains some bugs which I'm eliminating.
I use a general [try...catch] block wrapped around my application
[STAThread]
static void Main()
{
try
{
program = new Program();
// ...
}
catch (Exception x)
{
// ...
MessageBox.Show(
message,
Resources.MESSAGEBOX_ERROR_CRASH_Caption,
MessageBoxButtons.OK,
MessageBoxIcon.Error);
}
}
my Program class constructor being:
public Program()
{
// [...]
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
// [...]
frmLogon = new Logon();
Application.Run(frmLogon);
}
to ensure that any unhandled exception will bubble all the way up the stack and is at least responded to with some communicative message box.
It works fine when I run the application under Visual Studio (debug mode), but when I deployed it and installed on my PC, it doesn't - that's what I get when the bug (which I've already identified, by the way) causes it to read from a null array
Why? It baffles me really. Why was it "unhandled"? It was my understanding that try...catch should work regardless of whether it's release or debug mode, otherwise what would be the point.
This is kind of old, but if you still need a solution, you need to handle some events, enclosing the entire thing in a try catch won't work. Do something like this:
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
AppDomain.CurrentDomain.UnhandledException += ProcessAppException;
Application.ThreadException += ProcessThrException;
Application.Run(new MainForm());
}
private static void ProcessAppException(object sender, UnhandledExceptionEventArgs e)
{
XtraFunctions.LogException((Exception)e.ExceptionObject);
throw (Exception)e.ExceptionObject; //MessageBox in your case.
}
private static void ProcessThrException(object sender, ThreadExceptionEventArgs e)
{
XtraFunctions.LogException(e.Exception);
throw e.Exception; //MessageBox in your case.
}
When an exception isn't caught, it will go through one of those before displaying the exception dialog. So you have the option to override it and display a nice message of your choice.