I'm using ACRA in my application and can happily catch deliberately thrown exceptions in the UI code.
However if I throw the same type of exception in my background service ACRA does not catch and report the exception.
Should I expect ACRA to catch exceptions in a background service? If so do I need to do any additional configuration beyond the following which is in my application class attachBaseCOntext() method
CoreConfigurationBuilder builder = new CoreConfigurationBuilder(this);
builder.setBuildConfigClass(BuildConfig.class).setReportFormat(StringFormat.JSON);
builder.getPluginConfigurationBuilder(MailSenderConfigurationBuilder.class).setEnabled(true).setMailTo("kevin#electricpocket.com").setReportAsFile(true);
builder.getPluginConfigurationBuilder(ToastConfigurationBuilder.class).setEnabled(true).setResText(R.string.acra_toast_text);
ACRA.init(this, builder);
ACRA will only catch exceptions for the thread in which it is initialized.
I suspect your background service is running in another thread, and hence needs to initialize ACRA itself.
Related
How to implement an error monitoring in audio_service?
It runs in isolate, but none of methods available expose Isolate to add error listener. Thus is there any other method for hooking it to error monitoring platform like ex. sentry?
Good news and bad news.
When the UI isolate is present and initiates the method call to the background isolate, any exception generated by the background task will be forwarded to the UI isolate where you can create an error zone or use something like sentry. For example, an error thrown by onPlay in the background isolate will be forwarded and thrown by play in the main UI isolate.
However, when the UI isolate is not around, or the media notification initiates the method call to the background isolate, the exception will be caught and discarded internally.
Making the latter case an uncaught exception would make a good feature request. Although note that the next version of audio_service will run under a single isolate which would also solve the problem.
I'm using 3rd party library Cached network image, sometime it throws network errors, given these errors are thrown by a widget, asynchronously, how can I catch them?
or in general, if a 3rd party widget throws an exception, is there a way to catch it?
In CachedNetworkImage, you will get a callback errorWidget which will be returned only when a network error occurs or the URL is incorrect. You can return any widget that you want when the error occurs.
You cannot catch an error in CachedNetworkImage.
You can use Connectivity package to check for network related issues:
Link
I love SignalR and currently doing a few apps in it. Since SignalR is async if a logic error occurs on the service what is the best practice to handle that error?
I have been doing invoke to the client with an error object and adding it to a Reactive Extension observable, but that seems a little awkward.
The client is .Net Core and Blazor.
Suggestions?
SignalR is async if a logic error occurs on the service what is the best practice to handle that error?
ASP.NET Core SignalR provides built-in diagnostics logging feature that could help capture and log useful transports and Hub related information, which could help troubleshoot the issue.
Besides, from this doc, we can find:
Exceptions often contain sensitive information, such as connection information. Because of this, SignalR does not expose the details of exceptions that occur on the server to the client. However, instances of HubExceptionare sent to the client.
If you'd like to handle logic error occurs in Hub method, you can try to wrap the code logic in a try-catch block, then manually write exception in log.
Or you can create a new HubException instance with specified error message, which would be detected by client invoking this hub method.
try
{
//code logic here
//...
//...
//Convert.ToDateTime("hello");
await Clients.All.SendAsync("ReceiveMessage", user, message);
}
catch (Exception ex)
{
throw new HubException(ex.Message);
}
I am getting this error when i am trying to start my app
Handling of 'touchstart' input event was delayed for 2147483647 ms due to main thread being busy. Consider marking event handler as 'passive' to make the page more responsive.
Now I know that this is related to making event handlers passive but what I want to know is how to make event handlers passive in whole project because there are many types of event handlers used.
I am geting this error in my ionic.bundle.min.js file
I would like to have your suggestions on this.
I am new to ActiveVOS BPEL, please don't mind if my question seems dumb to you!
When we pass the data through SOAP UI, in ActiveVOS Designer upon removing the fault handler and change]ing the PDD Option "Suspend on uncaught Fault" to "true" for the BPEL process, I'm able to suspend and resume the process in the activeVOS Admin console.
Although, whenever I send the data through SOAP UI, it is giving me the time out exception without any response, but I could see the instance created in the Console.
When a request is sent through the SOAP UI, if we add FaultHandler to the BPEL process, the process directly ends up with the completed state. The options to resume the suspeneded process are disabled. Instead, I would like to resume the suspended process as well as response from the SOAP UI. Please address this and help me to achieve the intended result.
Thanks in advance!
the only thing that you can do is to place a scope (BPMN subprocess) and placing all activities from the initial receive (message catch event) to the initial reply (message throw event) in it. Then you can place an catch all fault handler in this scope. This will catch all errors that you want to suspend the process. Place a reply (message throw event) and a suspend after it in the fault handler. The reply will take care that the process caller will get some meaningful response and the ActiveVOS-specific suspend activity will then suspend the process. You can then rewind it or repair it by any means available in the ActiveVOS Console as long as you have a high enough persistence level configured in your PDD/server.