I am writing UI of an application using Haxe for CPP targets. I need to intercept haxe error/exceptions before it crashes the App.
Below is an example of code which crashes the application:
#:final private function callFoo(classA : IInterface) : Void
{
if ((mClassLevelVariable != null) && (classA != mClassLevelVariable))
{
throw new Error("Can not work with " + Type.getClassName(Type.getClass((classA))));
}
}
I need to intercept the crash before error like given above crashes the application. Do we have any support in Haxe like Java provides Thread.UncaughtExceptionHandler?
You could simply wrap your main() in a try-catch:
class Main {
static function main() {
try {
entryPoint();
} catch (e:Any) {
// do something with e
}
}
}
That's pretty much how for instance OpenFL implements Flash's uncaught error event as well.
Note that not all exceptions can be caught this way in hxcpp. Null pointer exceptions for instance can only be caught if HXCPP_CHECK_POINTER is defined.
Related
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.
I want to catch all 404 errors (controller not found) in my new cake app. But I don't have a clue how.
Is there any configuration for that? Or must I catch the thrown error by myself? If so, where?
Here is one approach, that could work. Define you own error handler, that extends default ErrorHandler
<?php
// Custom Handler - goes in src/Error/AppError.php
namespace App\Error;
use Cake\Routing\Exception\MissingControllerException;
use Cake\Error\ErrorHandler;
class AppError extends ErrorHandler
{
public function _displayException($exception)
{
if ($exception instanceof MissingControllerException) {
// Here handle MissingControllerException by yourself
} else {
parent::_displayException($exception);
}
}
}
Then register this handler as default.
// Register handler in config/bootstrap.php
use App\Error\AppError;
$errorHandler = new AppError();
$errorHandler->register();
http://book.cakephp.org/3.0/en/development/errors.html
I'm developing a J2ME Application and I want to make a good practice for Exception Handling, I'm throwing some exceptions like
ConnectionNotFoundException, IOException, XmlPullParserException, OutOfMemory, Exception
I don't want to catch all these exception in each method that I make
so I think that I can make a new class
and this class will handle all others
I have made this class
public class ExceptionHandler extends Exception {
private Exception thrownException;
public ExceptionHandler(Exception thrownExc) {
this.thrownException = thrownExc;
if (thrownException.getClass().isInstance(ConnectionNotFoundException.class)) {
// DO SOMETHING
} else if (thrownException.getClass().isInstance(IOException.class)) {
// DO SOMETHING
} else if (thrownException.getClass().isInstance(XmlPullParserException.class)) {
// DO SOMETHING
} else if (thrownException.getClass().isInstance(NullPointerException.class)) {
// DO SOMETHING
} else if (thrownException.getClass().isInstance(OutOfMemoryError.class)) {
// DO SOMETHING
} else if (thrownException.getClass().isInstance(Exception.class)) {
// DO SOMETHING
}
}
}
but I don't know if that is a good way or not and also I have error when I replace the thrown exceptions with mine
so what can I do please ?
You are on the right track, that is the best way to handle errors. You can also pass a second argument called message in your custom exception class and then display message here itself. Something like this:
if (thrownException.getClass().isInstance(ConnectionNotFoundException.class)) {
Dialog.alert(msg);
}
Also from the calling class, you just callnew ExceptionHandler(exception, Constants.msg)
The Constants.java class will hold all the error messages.
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);
}
}
}
}
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.