When implementing a custom queue, what is the best way to handle error? The documentation shows how to surface error in load message interceptor, but not how to surface error in QueueBase#intialize.
When load message interceptor returns or throws an ErrorData, cast.framework.events.EventType.ERROR will fire. But when QueueBase#initialize returns or throws an ErrorData (or any instance of Error, really), cast.framework.events.EventType.ERROR does not fire, which makes it impossible to handle those error.
Related
I have created a UI that has a listWidget with 10 items and I want to create a signal that that executes a custom slot when I double-click on a specific item of the listWidget (ie. the last one).
The signal/slot I implemented is as follows
QObject::connect(ui->listWidget_RD_commands, SIGNAL(QListWidget::itemDoubleClicked(ui->listWidget_RD_commands->item(9))), this, SLOT(flash_read));
It throws no errors but, in the application output window when I run the code, the following message pops up
When I try to implement the signal/slot with the new way
QObject::connect(ui->listWidget_RD_commands, &QListWidget::itemDoubleClicked(ui->listWidget_RD_commands->item(9)), this, &MainWindow::flash_read);
an error pops up saying
mainwindow.cpp:102:64: error: call to non-static member function without an object argument
So, what am I doing wrong here?
use anyhow::Context;
fancy_module::run()
.await
.with_context(|| {
format!("An error has been found")
})?;
From what I understand, when run returns an error, we return "An error has been found". But this message is not really meaningful. I would like to also return the error that run returns. Something like format!("An error has been found {}", e). How do I get e returned by run?
I could do that in multiple lines of code. By fetching the result of run and then having a match statement. Is there a nicer way of doing that?
From what I understand, when run returns an error, we return "An error has been found".
Not correct! context and with_context create a wrapper around the underlying error value to introduce additional context, but the original error is kept within!
Once you try displaying the error, you will see something of this sort:
Error: An error has been found
Caused by:
No such file or directory (os error 2)
(This also shows that "An error has been found" is a poor choice of words for creating additional context.)
I would like to also return the error that run returns. Something like format!("An error has been found {}", e).
That used to be a reasonable design decision in the past, but the current guidelines for error type design are against including the source error in the display message, unless that source error is also not reachable in the source error chain. The context methods will put the error in the source chain, so including that error's message into the top level error's message is ill advised.
How do I get e returned by run?
See the chain method in order to traverse the chain of source errors and so enable you to peek into underlying causes. Still, anyhow's error type was mostly designed to be opaque. If you need better introspection into what the error entails or easier pattern matching on errors, consider using a structural error type instead of anyhow::Error (snafu or thiserror can help you build them).
See also:
Should an Error with a source include that source in the Display output?
What is the difference between "context" and "with_context" in anyhow?
Simplier way to return custom error type with anyhow::Error?
I am trying to use asyncLocalStorage.getStore in an errorMiddleware after the application throws an error. I noticed that asyncLocalStorage.getStore was returning the right context right before the throw.
But if I add a try-catch around the throw, asyncLocalStorage.getStore() would return the right context. Wondering if context is loss through the error middleware
I want to show more beautiful error message to my users.
For example if someone types integer i= the error message no viable alternative at input '<EOF>' appears. That's totally fine and predictable due to my grammar rules but I'm figuring out ways to improve those messages. If the = is missing in the example above the message changes to mismatched input '<EOF>' expecting '='. Again predictable but I can do more stuff on things like this in my code than on a general input error.
Should I catch them in the code and try to evaluate which cases is meant? Or is there a better way to handle this?
Typically you'd create your own error listener and add it to the parser where you can deal with the error yourself. For that remove any existing error listeners (one for the console is automatically registered by default), by calling parser.removeErrorListeners();. Define an own error listener class derived from BaseErrorListener and add an instance of that to your parser via parser.addErrorListener(yourListener);. You can see an example of such a custom error listener in the ANTLR runtime (search for XPathLexerErrorListener). Override the syntaxError method and use the provided info to generate your own error message. There is already a message passed in to this method (in addition to other stuff like line + char position, exception etc.), which you cannot customize as it comes directly from generated code. So best is probably to leave that alone and start from scratch (the passed in exception is your best option you have).
We have a number of sections of code in the format:
try
{
// code
}
catch(std::exception &e)
{
// log exception
}
catch(...)
{
// log unknown exception.
}
Every so often, the unknown exception code triggers, and logs an unknown exception.
I always thought that all exceptions were meant to derive from std::exception, and thus catching std::exception would catch all exceptions.
Is there some other exception that I should be catching?
If my code ends up in the unknown exception handler, is there any way that I can find out what exception was actually caught?
edit
We managed to locate the cause of the problem- despite saying that they had, the customer had not installed .NET 3.5, which our code depends on, and the system fell over when trying to use the XML parser.
Is there some other exception that I should be catching?
This depends on your code. Libraries you call can throw exceptions not derived from std::exception, examples are MFC's CException or Microsoft's _com_error. Also, an access violation might be catched by catch(...), which is the reason why I would not use catch(...) in my code - it's just to broad for me.
2.If my code ends up in the unknown exception handler, is there any way that I can find out what exception was actually caught?
You can run your code in the debugger and configure the debugger to break your program when the exception is thrown (first chance). Then you know exactly which line of code triggers the exception and should be able to see what exactly is thrown.