Flutter catching all unhandled exceptions - exception

I'm trying to catch all unhandled exceptions in a Flutter app so I can sent it to a crash reporter. There are instructions on how to do this in the Flutter docs. I followed those, and added two bits of code to my app to catch exceptions:
Catch Dart errors by wrapping runApp in runZoned:
runZoned<Future<void>>(
() async {
runApp(MyApp());
},
onError: (dynamic error, StackTrace stackTrace) {
print("=================== CAUGHT DART ERROR");
// Send report
},
);
Catch flutter errors by setting FlutterError.onError:
FlutterError.onError = (FlutterErrorDetails details) {
print("=================== CAUGHT FLUTTER ERROR");
// Send report
};
However, when I test this at runtime by throwing an exception from a button:
throw Exception("Just testing");
The exception appears in the console:
════════ Exception Caught By gesture
═══════════════════════════════════════════════════════════════
The following _Exception was thrown while handling a gesture: Exception:
Just testing When the exception was
thrown, this was the stack:
... etc
But I see no sign of my print statements (CAUGHT DART ERROR or CAUGHT FLUTTER ERROR), and setting breakpoints on those lines never seems to hit, so I think my exception handling code isn't catching it. Am I missing something?
Here's a minimal reproducible example (click the button, which throws an exception, but it's not caught as expected):
import 'dart:async';
import 'package:flutter/material.dart';
void main() =>
runZoned<Future<void>>(
() async {
runApp(MyApp());
},
onError: (dynamic error, StackTrace stackTrace) {
print("=================== CAUGHT DART ERROR");
// Send report
// NEVER REACHES HERE - WHY?
},
);
class MyApp extends StatefulWidget {
// This widget is the root of your application.
#override
_MyAppState createState() => _MyAppState();
}
class _MyAppState extends State<MyApp> {
#override
void initState() {
super.initState();
// This captures errors reported by the FLUTTER framework.
FlutterError.onError = (FlutterErrorDetails details) {
print("=================== CAUGHT FLUTTER ERROR");
// Send report
// NEVER REACHES HERE - WHY?
};
}
#override
Widget build(BuildContext context) {
return MaterialApp(
home: Scaffold(
body: SafeArea(
child: RaisedButton(
child: Text("Throw exception"),
onPressed: () {
throw Exception("This is a test exception");
},
),
),
),
);
}
}

Okay I figured out what's going on. Had a look at some related Flutter issues:
flutter tool is too aggressive about catching exceptions
Make hot mode a little less aggressive about catching errors
Break on "unhandled" exceptions when a debugger is attached
It looks like when in debug mode, the flutter framework catches a lot of exceptions, prints to the console (and sometimes shows in the UI itself in red and yellow), but doesn't re-throw - so they are effectively swallowed and there's no way for your own code to catch them. But, when you deploy in release mode, this doesn't happen. So my minimal reproducible example does catch exceptions when built in release mode.

Note: Sample code updated for onError deprecated warning by using runZonedGuarded
Hi #james Allen I think all the unhandled error can be catch globally & it can handle or print in console regardless of modes. In your example I think you missed to add this line WidgetsFlutterBinding.ensureInitialized() before setting up flutterError.onError so it works as you except.
To handle the unhandled exceptions in flutter we have get help from these safety wraps up to catch those exception, which are listed below
Zone ( to catch all unhandled-asynchronous-errors )
FlutterError.onError ( to catch all unhandled-flutter-framework-errors )
ZONE :
zone are not-belong to flutter framework, it's from dart itself. In dart documentation it states that..
zone protecting your app from exiting due to an uncaught exception
thrown by asynchronous code
Reference link : https://dart.dev/articles/archive/zones#handling-asynchronous-errors
so by wrapping our app inside zone to our flutter app, helps to catch all the unhandled-asynchronous-errors below its simple code.
Example:
void main() {
runZonedGuarded(() async {
runApp(MyApp()); // starting point of app
},(error, stackTrace) {
print("Error FROM OUT_SIDE FRAMEWORK ");
print("--------------------------------");
print("Error : $error");
print("StackTrace : $stackTrace");
});
}
FlutterError.onError :
from official flutter documentation it says,
The Flutter framework catches errors that occur during callbacks
triggered by the framework itself, including during build, layout, and
paint.
All these errors are routed to the FlutterError.onError handler. By
default, this calls FlutterError.dumpErrorToConsole,
Reference link : https://flutter.dev/docs/testing/errors
so by using flutterError.onError we can able to catch all the flutter framework related errors, below its simple example..
Example:
void main() {
WidgetsFlutterBinding.ensureInitialized(); //imp line need to be added first
FlutterError.onError = (FlutterErrorDetails details) {
//this line prints the default flutter gesture caught exception in console
//FlutterError.dumpErrorToConsole(details);
print("Error From INSIDE FRAME_WORK");
print("----------------------");
print("Error : ${details.exception}");
print("StackTrace : ${details.stack}");
};
runApp(MyApp()); // starting point of app
}
don't forget to add this line WidgetsFlutterBinding.ensureInitialized() first before setting up the flutter framework's error catching helper.
Note:
Flutter red screen to death error will also catch under flutterError.onError catcher.
Flutter red screen will be visible in dev mode by default in production it will be as just plain BG as per flutter documentation.
Flutter screen to death can be customizable as per our creativity.
Flutter wont kill the app, even the exception are not handled by these helpers.
Bonus one - these is also library called catcher in pub.dev which you might take a look for error catching.
combination of these two helper from dart & flutter framework we can catch all the unhandled errors globally, these are all which I understand from the web documentations when I was assigned for global exception handling task in flutter, feel free to correct me if any mistakes.

Make sure you're using WidgetsFlutterBinding.ensureInitialized() like this
runZonedGuarded(() {
WidgetsFlutterBinding.ensureInitialized(); //<= the key is here
FlutterError.onError = (FlutterErrorDetails errorDetails) {
Utilities.log("Will log here ${errorDetails.exception.toString()}");
};
runApp(app);
}, (error, stackTrace) {
Utilities.log("Others catching ${error.toString()}");
});

So the 'runZoned' and the 'Flutter.onError' are for 'error' handling in dart and flutter framework respectively. But in your code you are throwing an 'exception'. Which is not handled by the 'run..' or '..onErr'. If you want to see the "Just testing" in the console, modify the throw statement as follows -> throw "Just testing"; and you will see it in the console logs.

Related

C++Winrt how to throw and handle exception without terminating program

I have following code
IAsyncOperation<bool> trythiswork()
{
bool contentFound{ false };
try
{
auto result = co_await someAsyncFunc();
winrt::check_bool(result)
if (result)
{
contentFound = true;
}
}
catch (...)
{
LOG_CAUGHT_EXCEPTION();
}
co_return contentFound;
}
When the result is false, it fails and throws but catch goes to fail fast and program terminates. How does log function terminate the program? Isn't it supposed to only log the exception? I assumed that I am handling this exception so program won't crash but it is crashing.
So how to throw and catch so that program does not terminate? I do want to throw. And also catch and preferably log the exception as well.
Thanks
The issue can be reproduced using the following code:
IAsyncOperation<bool> someAsyncFunc() { co_return false; }
IAsyncOperation<bool> trythiswork()
{
auto contentFound { false };
try
{
auto result = co_await someAsyncFunc();
winrt::check_bool(result);
// throw std::bad_alloc {};
contentFound = true;
}
catch (...)
{
LOG_CAUGHT_EXCEPTION();
}
co_return contentFound;
}
int main()
{
init_apartment();
auto result = trythiswork().get();
}
As it turns out, everything works as advertised, even if not as intended. When running the code with a debugger attached you will see the following debug output:
The exception %s (0x [trythiswork]
Not very helpful, but it shows that logging itself works. This is followed up by something like
FailFast(1) tid(b230) 8007023E {Application Error}
causing the process to terminate. The WIL only recognizes exceptions of type std::exception, wil::ResultException, and Platform::Exception^. When it handles an unrecognized exception type it will terminate the process by default. This can be verified by commenting out the call to check_bool and instead throwing a standard exception (such as std::bad_alloc). This produces a program that will log exception details, but continue to execute.
The behavior can be customized by registering a callback for custom exception types, giving clients control over translating between custom exception types and HRESULT values. This is useful in cases where WIL needs to interoperate with external library code that uses its own exception types.
For C++/WinRT exception types (based on hresult_error) the WIL already provides error handling helpers that can be enabled (see Integrating with C++/WinRT). To opt into this all you need to do is to #include <wil/cppwinrt.h> before any C++/WinRT headers. When using precompiled headers that's where the #include directive should go.
With that change, the program now works as desired: It logs exception information for exceptions that originate from C++/WinRT, and continues to execute after the exception has been handled.

exception tracking and blocking it in zend framework 2

How to stop exception from showing in zend framework 2 and instead when exception is thrown i want to redirect to 404 page .
Actually when user fires wrong url or some how any query gets executed in a wrong way exception is thrown , so i need to block this exception and instead redirect to any other well designed page . I'm unable to track the the exception point or rather catch the exception or from where exception is generated . I have used this code
You can handle the exceptions in anyway you want after catching it as the following example in which you are catching the exception globally...:
In the onBootstrap method i have attached the following code in Module.php in a function to execute when an event occurs, the following attach a function to be executed when an error (exception) is raised:
public function onBootstrap(MvcEvent $e)
{
$application = $e->getApplication();
$em = $application->getEventManager();
//handle the dispatch error (exception)
$em->attach(\Zend\Mvc\MvcEvent::EVENT_DISPATCH_ERROR, array($this,
'handleError'));
//handle the view render error (exception)
$em->attach(\Zend\Mvc\MvcEvent::EVENT_RENDER_ERROR, array($this,
'handleError'));
}
and then defineed in module.php only the function to handle the error
public function handleError(MvcEvent $e)
{
//get the exception
$exception = $e->getParam('exception');
//...handle the exception... maybe log it and redirect to another page,
//or send an email that an exception occurred...
}
I found this code from stackoverflow only , but it is not working , i mean when i'm passing wrong parameters in url , it is showing " A 404 error occurred
Page not found.
The requested controller was unable to dispatch the request.
Controller:
Front\Controller\Front
No Exception available "
Please i need help on this.
you can turn off exceptions in zf2 by chaining 'display_exceptions' => TRUE to 'display_exceptions' => false, [module/Application/config/module.config.php]

WinRt. UnhandledException handler. StackTrace is null

I have a project on WinForms with this code:
AppDomain.CurrentDomain.UnhandledException += CurrentDomainUnhandledException;
private void CurrentDomainUnhandledException(object sender, UnhandledExceptionEventArgs e)
{ }
The e.ExceptionObject contains full StackTrace.
In Win Store project:
this.UnhandledException += (s, e) =>{
{
MarkedUp.AnalyticClient.LogLastChanceException(e);
};
e.Exception.StackTrace is null.
Both exceptions were generated by this code:
int a=0;
....
try
{
int i = 1 / a;
}
catch (Exception exp)
{
throw;
}
Any Ideas?
The reference on MSDN suggests that this is a limitation: http://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.application.unhandledexception
A notable limitation is that the UnhandledException event arguments don’t contain as much detail as the original exception as propagated from app code. Whenever possible, if the app requires specific processing of a certain exception, it’s always better to catch the exception as it propagates, because more detail will be available then. The UnhandledException event arguments expose an exception object through the Exception property. However, the type, message, and stack trace of this exception object are not guaranteed to match those of the original exception that was raised. The event arguments do expose a Message property. In most cases, this will contain the message of the originally raised exception.
Are you running the solution in Debug mode? There seems to be happening something in the App.g.i.cs file when you run the solution in Debug mode. When I run your sample in Release mode the stacktrace is available in the UnhandledException event.
In my test solution it breaks first here:
#if DEBUG && !DISABLE_XAML_GENERATED_BREAK_ON_UNHANDLED_EXCEPTION
UnhandledException += (sender, e) =>
{
if (global::System.Diagnostics.Debugger.IsAttached) global::System.Diagnostics.Debugger.Break();
};
#endif
And after that one it goes to the UnhandledException handler that I have defined in the app.xaml.cs file. In Debug the stacktrace is gone, in Release mode the stacktrace and the exception details are there.

How can I wait on tasks without throwing TaskCanceledExceptions?

I have a method that creates some Tasks, and then waits on them with WaitAll before returning. The problem is, if those tasks got canceled, then WaitAll throws an AggregateException containing lots of TaskCanceledExceptions.
That means that WaitAll will throw exceptions in two different circumstances:
Exceptions that indicate a genuine error. These mean that there was a condition we didn't know how to handle; they need to propagate as unhandled exceptions, until they eventually terminate the process.
Exceptions that indicate that the user clicked a Cancel button. These mean that the task was canceled and cleaned up, and the program should continue running normally.
The latter fits squarely into the definition of a vexing exception: it's an exception thrown in a completely non-exceptional circumstance, so I have to catch it in order to resume normal control flow. Fortunately it's easy to catch, right? Just add catch (AggregateException) and -- oh wait, that's the same type that gets thrown when there's a fatal error.
I do need to wait for the tasks to finish running before I return (I need to know that they're no longer using their database connections, file handles, or anything else), so I do need the WaitAll or something similar. And if any of the tasks faulted, I do want those exceptions to propagate as unhandled exceptions. I just don't want exceptions for cancel.
How can I prevent WaitAll from throwing exceptions for canceled tasks?
The AggregateException provides a Handle method that can be used for these situations. If for example you want to ignore TaskCanceledException you can do:
var all = new AggregateException(
new NullReferenceException(),
new TaskCanceledException(),
new TaskCanceledException(),
new InvalidOperationException(),
new TaskCanceledException());
try
{
throw all;
}
catch (AggregateException errors)
{
errors.Handle(e => e is TaskCanceledException);
}
If all the exceptions are of type TaskCanceledException, the Handle method will not throw any exception; otherwise a new AggregateException containing only the unhandled exceptions will be thrown.
Based on João Angelo's suggestion, here goes a Task class extension
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
namespace MySharedLibrary.Extensions
{
public static class TaskExtensions
{
// This code is based João Angelo's stackoverflow suggestion https://stackoverflow.com/a/8681687/378115
// Use this when a CancellationTokenSource is used
public static void SafeWait(this Task TargetTask, CancellationTokenSource TargetTaskCancellationTokenSource)
{
if (TargetTaskCancellationTokenSource.IsCancellationRequested == false)
{
TargetTaskCancellationTokenSource.Cancel();
}
SafeWait(TargetTask);
}
// Use this when no CancellationTokenSource is used
public static void SafeWait(this Task TargetTask)
{
try
{
if (TargetTask.IsCanceled == false)
{
TargetTask.Wait();
}
}
catch (AggregateException errors)
{
errors.Handle(e => e is TaskCanceledException);
}
}
}
}

Groovy end exception different from exception thrown

I am running into an extremely strange behavior in Groovy. When I throw an exception from a closure in a Script, the end exception that was thrown was different.
Here are the code and the details:
public class TestDelegate {
def method(Closure closure) {
closure.setResolveStrategy(Closure.DELEGATE_FIRST);
closure.delegate = this;
closure.call();
}
public static void main(String[] args) {
// Make Script from File
File dslFile = new File("src/Script.dsl");
GroovyShell shell = new GroovyShell();
Script dslScript = shell.parse(dslFile);
TestDelegate myDelegate = new TestDelegate();
dslScript.metaClass.methodMissing = {
// will run method(closure)
String name, arguments ->
myDelegate.invokeMethod(name, arguments);
}
dslScript.metaClass.propertyMissing = {
String name ->
println "Will throw error now!"
throw new MyOwnException("errrrror");
}
dslScript.run();
}
}
class MyOwnException extends Exception {
public MyOwnException(String message) {
super(message);
}
}
Script.dsl:
method {
println a;
}
So the plan is that when I run the main() method in TestDelegate, it will run the DSL script, which calls for the method method(). Not finding it in the script, it will invoke methodMissing, which then invokes method() from myDelegate, which in turns invoke the closure, setting the delegate to the testDelegate. So far, so good. Then the closure is supposed to try printing out "a", which is not defined and will thus set off propertyMissing, which will will throw MyOwnException.
When I run the code, however, I get the following output:
Will throw error now!
Exception in thread "main" groovy.lang.MissingPropertyException: No such property: a for class: TestDelegate
Now, it must have reached that catch block, since it printed "Will throw error now!" It must have thrown MyOwnException too! But somewhere along the lines, MyOwnException was converted to MissingPropertyException, and I have no idea why. Does anyone have any idea?
P.S. if I remove closure.setResolveStrategy(Closure.DELEGATE_FIRST) from TestDelegate#method(), the code acts as expected and throws MyOwnException. But I really need the setResolveStrategy(Closure.DELEGATE_FIRST) for my DSL project. And I would prefer to know the root cause of this rather than just removing a line or two and see that it works without understanding why.
I think this is what essentially happens: With a delegate-first resolve strategy, the Groovy runtime first tries to access property a on myDelegate, which results in a MissingPropertyException because no such property exists. Then it tries propertyMissing, which causes a MyOwnException to be thrown. Eventually the runtime gives up and rethrows the first exception encountered (a design decision), which happens to be the MissingPropertyException.
With an owner-first resolve strategy, propertyMissing is consulted first, and hence MyOwnException is eventually rethrown.
Looking at the stack trace and source code underneath should provide more evidence.