I signed up for the jira.. not sure how to report issues except for pull request. There's a bug here as the result of .get() can be null. Possibly there is better information available to hydrate an exception I think.
In org.voltdb.Distributer
if (m_partitionUpdateStatus.get().getStatus() != ClientResponse.SUCCESS) {
throw new ProcCallException(m_partitionUpdateStatus.get(), null, null);
}
Example stack trace
org.voltdb.client.ProcCallException: null
at org.voltdb.client.Distributer.getPartitionKeys(Distributer.java:1561) ~[voltdbclient-8.4.1.jar!/:?]
at org.voltdb.client.ClientImpl.callAllPartitionProcedure(ClientImpl.java:1071) ~[voltdbclient-8.4.1.jar!/:?]
at zipkin2.autoconfigure.storage.voltdb.VoltDBScheduledTasks.processCompleteTraces(VoltDBScheduledTasks.java:54) ~[voltdb.jar!/:?]
I logged a bug ticket for this: https://issues.voltdb.com/browse/ENG-15784
If you catch the exception, you could call ProcCallException.getClientResponse().getStatusString() which should show why the client wasn't able to get the partition key values that it needs to process a callAllPartitionProcedure() invocation.
Disclosure: I work at VoltDB
Related
I have an updateDocument method in a class for a service layer in a node.js, express, mongoose application. I'm wondering what is the best practice for handing cases where the update method didn't update a document, for example if the wrong id is passed in.
Version 1: If the update wasn't successful, return an object with success: false:
async updateDocument(id, updates) {
const output = await this.DocumentModel.updateOne({ _id: id }, updates);
let message = 'Something went wrong';
let success = false;
let updatedItem = null;
if (output.nModified) {
message = 'Successfully updated document.';
success = true;
updatedItem = await this.getDocument(id);
}
return { message, success, updatedItem};
}
Version 2: If the update wasn't successful, throw an error:
async updateDocument(id, updates) {
const output = await this.DocumentModel.updateOne({ _id: id }, updates);
let updatedItem;
if (output.nModified) {
updatedItem = await this.getDocument(id);
} else{
throw new Error("The document wasn't updated")
}
return updatedItem;
}
Do you always throw an exception when the input, such as a bad id, isn't correct? Or could you return information about the update being a success or not? As newbie node.js developer, I'm not sure I am grasping the full picture enough to recognize problems with either method.
There is no golden way, only principles that lead to robust and well-maintainable software.
Generally, you should use a try-catch-statement for all kinds of errors that are not in your control (connections, disk space, credentials, ...) . The errors should then be handled as soon as possible, but not before. The reason for this is that you often don't know, yet, how to handle an error in an appropriate manner at a lower layer.
For logical "errors" that you can expect (wrong input format, missing username, unknown options, ...), you should use an if-statement or a validation function and then throw an error, if anything is not as expected.
In your case, you should check, if the methods updateOne or getDocument can throw errors. If yes, you should wrap these functions with a try-catch-statement.
A few more tips:
Both versions of your code are good. But I would prefer version 2 because it is more concise.
If you are sure that there is always an output object, you can destruct the nModified property like this:
const { nModified } = await this.DocumentModel.updateOne({ _id: id }, updates);
If you use a negative if-statement, you can reduce the depth of indentation and you can use const variables:
if (!nModified) {
throw new Error("The document wasn't updated")
}
const updatedItem = await this.getDocument(id);
Now, you could also directly return this.getDocument(id) and don't need the variable updatedItem anymore.
You can finally handle your errors in your controller classes.
You can use custom error classes to be consistent in your error handling and error messages all over your app.
I hope this is at least a bit helpful.
References
These are some similar questions with good answers. But you need to take care because many code examples are not in modern JavaScript.
A general discussion about the pros and cons of Error-Handling vs.
if-else-statements is done here:
What is the advantage of using try {} catch {} versus if {} else {}
Error-Handling in Node.js is discussed here in this thread:
Node.js Best Practice Exception Handling
It seemed like there were a lot of different opinions on this and not one go-to method. Here's some information I found and what I ended up doing.
When to throw an exception?
Every function asks a question. If the input it is given makes that question a fallacy, then throw an exception. This line is harder to draw with functions that return void, but the bottom line is: if the function's assumptions about its inputs are violated, it should throw an exception instead of returning normally.
Should a retrieval method return 'null' or throw an exception when it can't produce the return value?
Answer 1:
Whatever you do, make sure you document it. I think this point is more important than exactly which approach is "best".
Answer 2:
If you are always expecting to find a value then throw the exception if it is missing. The exception would mean that there was a problem.
If the value can be missing or present and both are valid for the application logic then return a null.
More important: What do you do other places in the code? Consistency is important.
Where should exceptions be handled?
Answer 1: in the layer of code that can actually do something about the error
Exceptions should be handled in the layer of code that can actually do something about the error.
The "log and rethrow" pattern is often considered an antipattern (for exactly the reason you mentioned, leads to a lot of duplicate code and doesn't really help you do anything practical.)
The point of an exception is that it is "not expected". If the layer of code you are working in can't do something reasonable to continue successful processing when the error happens, just let it bubble up.
If the layer of code you are working in can do something to continue when the error happens, that is the spot to handle the error. (And returning a "failed" http response code counts as a way to "continue processing". You are saving the program from crashing.)
-source: softwareengineering.stackexchange
Answer 2: Handle errors centrally, not within a middleware
Without one dedicated object for error handling, greater are the chances of important errors hiding under the radar due to improper handling. The error handler object is responsible for making the error visible, for example by writing to a well-formatted logger, sending events to some monitoring product like Sentry, Rollbar, or Raygun. Most web frameworks, like Express, provide an error handling middleware mechanism. A typical error handling flow might be: Some module throws an error -> API router catches the error -> it propagates the error to the middleware (e.g. Express, KOA) who is responsible for catching errors -> a centralized error handler is called -> the middleware is being told whether this error is an untrusted error (not operational) so it can restart the app gracefully. Note that it’s a common, yet wrong, practice to handle errors within Express middleware – doing so will not cover errors that are thrown in non-web interfaces.
-source; Handle errors centrally, not within a middleware
More: Best Practice Node.js: Error Handling
So it seems like these two principles disagree. #1 says to handle it right away if you can. So for me it would be in the service layer. But the #2 says handle it centrally, like in the server file. I went with #2.
My decision: throw the error in a custom error class
It combined a few methods people suggested. I am throwing the error, but I'm not "log and rethrow"-ing, as the answer above warned against. Instead, I put the error in a custom error with more information and throw that. It is logged and handled centrally.
So first in my service layer this is how an error is thrown:
async addUser(user) {
let newUser;
try {
newUser = await this.UserModel.create(user);
} catch (err) {
throw new ApplicationError( // custom error
{
user, // params that are useful
err, //original error
},
`Unable to create user: ${err.name}: ${err.message}` // error message
);
}
return newUser;
}
ApplicationError is a custom error class that takes an info object and a message. I got this idea from here:
In this pattern, we would start our application with an ApplicationError class this way we know all errors in our applications that we explicitly throw are going to inherit from it. So we would start off with the following error classes:
-source: smashingmagazine
You could put other helpful information in your custom error class, even maybe what EJS template to use! So you could really handle the error creatively depending on how you structure your custom error class. I don't know if that's "normal", maybe it's not SOLID to include the EJS template, but I think it's an interesting concept to explore. You could think about other ways that might be more SOLID to dynamically react to errors.
This is the handleError file for now, but I will probably change it up to work with the custom error to create a more informative page. :
const logger = require("./logger");
module.exports = (err, req, res, next) => {
if (res.headersSent) {
return next(err);
}
logger.log("Error:", err);
return res.status(500).render("500", {
title: "500",
});
};
Then I add that function to my server file as the last middleware:
app.use(handleError);
In conclusion, it seems like there's a bit of disagreement on how to handle errors though it seems more people think you should throw the error and probably handle it centrally. Find a way that works for you, be consistent, and document it.
I'm currently writing a public REST service in Node.js that interfaces with a Postgres-database (using Sequelize) and a Redis cache instance.
I'm now looking into error handling and how to send informative and verbose error messages if something would happen with a request.
It struck me that I'm not quite sure how to handle internal server errors. What would be the appropriate way of dealing with this? Consider the following scenario:
I'm sending a post-request to an endpoint which in turn inserts the content to the database. However, something went wrong during this process (validation, connection issue, whatever). An error is thrown by the Sequelize-driver and I catch it.
I would argue that it is quite sensitive information (even if I remove the stack trace) and I'm not comfortable with exposing references of internal concepts (table-names, functions, etc.) to the client. I'd like to have a custom error for these scenarios that briefly describes the problem without giving away too detailed information.
Is the only way to approach this by mapping every "possible" error in the Sequelize-driver to a generic one and send that back to the client? Or how would you approach this?
Thanks in advance.
Errors are always caused by something. You should identify and intercept these causes before doing your database operation. Only cases that you think you've prepared for should reach the database operation.
If an unexpected error occurs, you should not send an informative error message for security reasons. Just send a generic error for unexpected cases.
Your code will look somewhat like this:
async databaseInsert(req, res) {
try {
if (typeof req.body.name !== 'string') {
res.status(400).send('Required field "name" was missing or malformed.')
return
}
if (problemCase2) {
res.status(400).send('Error message 2')
return
}
...
result = await ... // database operation
res.status(200).send(result)
} catch (e) {
res.status(500).send(debugging ? e : 'Unexpected error')
}
}
I have a question, in the PDO manuial somewhere I read that errors reveal the db connect with username and password (due to a flaw in the zend engine). I see several examples of catching the pdo like this:
catch(PDOException $exception){
return $exception;
}
if the exception is returned, doesn't the user see the error?
Is it better to have disabled the error reporting in the php.ini file, or even do something like
setAttribute(PDO::ERRMODE_SILENT)
instead of the catch statement, or is it better to do a combination of above and redo the catch statement so it doesn't return the error to the user.
This is referring to the pink paragraph on the manual page that says: Warning: If your application does not catch the exception thrown from the PDO constructor, the default action taken by the zend engine is to terminate the script and display a back trace. This back trace will likely reveal the full database connection details, including the username and password. It is your responsibility to catch this exception, either explicitly (via a catch statement) or implicitly via set_exception_handler(). php.net/manual/en/pdo.connections.php.
The user "YOUR COMMON SENSE" marked this as duplicate which is not correct. I don't have an issue with using PDO, Its just a question of dealing with error responses, and correct methodology of error handling.
My UWP app is crashing in Release mode and works fine in Debug mode but I can't put my finger on what the issue is but I know it's related to a combination of raising an event from System.Threading.Timer and MVVMLight.
I created an new dummy application and use the same code (ZXing.net.mobile where I used 2 portable libraries and I used my own user control which is a simplified version of theirs - I'm using events instead of <Action>). This works fine and I'm currently trying to put more steps into it i.e. include mvvmlight and navigation but so far, I can't reproduce the problem in this dummy app.
The error I'm getting is:
Unhandled exception at 0x58C1AF0B (mrt100_app.dll) in Company.MyApp.App.exe:
0xC0000602: A fail fast exception occurred. Exception handlers will not be
invoked and the process will be terminated immediately.
Followed by:
Unhandled exception at 0x0107D201 (SharedLibrary.dll) in
Company.MyApp.App.exe: 0x00001007.
When looking at the Threads window, one of the worker thread has the following information if that's of help.
Not Flagged > 4012 0 Worker Thread <No Name>
System.Private.Interop.dll!System.Runtime.InteropServices.
ExceptionHelpers.ReportUnhandledError Normal
[External Code]
System.Private.Interop.dll!System.Runtime.InteropServices.ExceptionHelpers.
ReportUnhandledError(System.Exception e) Line 885
System.Private.Interop.dll!Internal.Interop.InteropCallbacks.ReportUnhandledError
(System.Exception ex) Line 17
System.Private.WinRTInterop.CoreLib.dll!Internal.WinRT.Interop.WinRTCallbacks.
ReportUnhandledError(System.Exception ex) Line 274
System.Private.CoreLib.dll!System.RuntimeExceptionHelpers.ReportUnhandledException
(System.Exception exception) Line 152
System.Private.Threading.dll!System.Threading.Tasks.AwaitTaskContinuation.
ThrowAsyncIfNecessary(System.Exception exc) Line 784
System.Private.Threading.dll!System.Threading.WinRTSynchronizationContext.Invoker.
InvokeCore() Line 182
System.Private.Threading.dll!System.Threading.WinRTSynchronizationContext.Invoker.
Invoke(object thisObj) Line 162
System.Private.CoreLib.dll!System.Action<System.__Canon>.
InvokeOpenStaticThunk(System.__Canon obj)
System.Private.WinRTInterop.CoreLib.dll!Internal.WinRT.Interop.WinRTCallbacks.PostToCoreDispatcher.AnonymousMethod__0() Line 266
MyCompany.MyApp.App.exe
MyCompany.MyApp.App.ViewModels.ValidateHandler.Invoke(string pin)
MyCompany.MyApp.App.McgInterop.dll!McgInterop.ReverseComSharedStubs
.Proc_(object __this, System.IntPtr __methodPtr) Line 6163
MyCompany.MyApp.App.McgInterop.dll!Windows.UI.Core.DispatchedHandler__Impl.Vtbl.Invoke__STUB(System.IntPtr pComThis) Line 45147
[External Code]
Within my QR Code UserControl, it's using a System.Threading.Timer and it raises an event when a QR Code is found:
timerPreview = new Timer(async (state) =>
{
....
// Check if a result was found
if (result != null && !string.IsNullOrEmpty(result.Text))
{
Debug.WriteLine("Barcode Found: " + result.Text);
if (!this.ContinuousScanning)
{
delay = Timeout.Infinite;
await StopScanningAsync();
}
else
{
delay = this.ScanningOptions.DelayBetweenContinuousScans;
}
OnBarcodeFound(result.Text);
}
timerPreview.Change(delay, Timeout.Infinite);
}, null,
this.ScanningOptions.InitialDelayBeforeAnalyzingFrames,
Timeout.Infinite);
In the page that host the QRCode UserControl, I've got the following code:
private async void ScannerControl_BarcodeFound(string barcodeValue)
{
var dispatcher = CoreApplication.MainView.CoreWindow.Dispatcher;
await dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, () => {
Debug.WriteLine(barcodeValue);
GetViewModel.BarcodeFound(barcodeValue);
});
}
As you can see, I'm passing the QrCode value to my ViewModel and from there, I sent a message and then re-direct to another page:
public void BarcodeFound(string barcodeData)
{
Messenger.Default.Send<string>(barcodeData, MessengerTokens.QrCodeFound);
this.NavigationFacade.NavigateToMyOtherPage();
}
I could keep going and provide additional code, but as I add additional breakpoints I can see that the code and passing the correct value and going to the correct location but eventually it throws this error. If I add additional error handlers or dispatcher code, it eventually works and goes to the next page as expected but when I click on a button in my CommandBar, it then takes a while and it eventually throws the same error, so by adding these additional bits of code, I feel I'm just pushing down the problem further down the line.
Anyone got any suggestions on how I get around this problem. I wish I could share the full app but definitely can't. So I know it will be hard to provide a solution, but if anyone has suggestions I'd appreciate them.
As I said, I think the issue is a result of a combination of threading and mvvmlight but it's driving me nuts that my test app so far is working exactly as expected, so I'm pretty sure it's not Zxing or my UserControl.
Any help, suggestions would be greatly appreciated or if you need me to provide additional info, please let me know what and I'll try to provide it.
Thanks.
Well, this was a painstaking exercise and a huge waste of my time!
It was down to a few things!!
I was using a different DataService in Releasemode which wasn't implemented. By implemented, I mean all my functions were returning the NotImplementedException or null values.
When passing my model to my ViewModel, I did not check if it was null, thus causing unhandled exceptions.
I had a chain of mvvmlight events (Messenger.Default.Send<>) being triggered and none were checking for error or null values.
While all of these were caused by poor validation from my part, these errors are extremely poorly reported in Release mode! if from the get go, I had received a NullReferenceException or any kind of exceptions, it would have put me in the right direction immediately, but throwing errors such as the one I've had were totally useless but it didn't but lesson learned!!
All I can say is that if this problem ever happens to you, don't waste your time rewriting code or trying to find workarounds. First work your way through your workflow/chain of events and hopefully, you'll eventually catch the culprit.
Hope this helps.
Sadly we were facing a similar issue, ours was involved with setting the qualifier values for changing localization on the fly in the app but came up with mystery fail fast/SharedLibrary native errors. Upgrading the Microsoft.NETCore.UniversalWindowPlatform package from 6.0.4 to 6.0.7 seems to have resolved the issue.
Only thought of this because another place I was researching this error involved someone solving a SharedLibrary problem by upgrading their NETCore package, that case was an earlier one (5.x), but figured it was worth a shot.
I am trying to understand how to build my error handling system for my api.
Let's say I have a the following line in a controller method :
var age = json.info.age;
with
json = {"id":1, "name":"John", info": {"age":27, "sex":"m"}}
Let's say that the object doesn't contain an info field, I'll get the following error TypeError: Cannot read property 'info' of undefined and my server will crash.
Is there a way to make a higher level abstraction and catch all the potential errors that I could have? Or should I have a try/catch system for each of the methods of my controllers?
BEWARE OF THE CODE BELOW, IT WILL BITE YOU WHENEVER IT CAN!
Don't use the code snippet below if you do not understand its
implications, please read the whole answer.
You can use the node way for uncaught errors. Add this in your config/bootstrap.js
Updated the snippet below to add what was said in the comments, also added a warning about using a global to respond to the user.
process.on('uncaughtException', function (err) {
// Handle your errors here
// global.__current__ is added via middleware
// Be aware that this is a bad practice,
// global.__current__ being a global, can change
// without advice, so you might end responding with
// serverError() to a different request than the one
// that originated the error if this one happened async
global.__current__.res.serverError();
})
Now, can doesn't mean should. It really depends on your needs, but do not try to catch BUGS in your code, try to catch at a controller level the issues that might not happen every time but are somehow expected, like a third-party service that responded with empty data, you should handle that in your controller. The uncaughtException is mainly for logging purposes, its better to let your app crash if there is a bug. Or you can do something more complicated (that might be better IMHO), which is to stop receiving requests, respond to the error 500 (or a custom one) to user that requested the faulty endpoint, and try to complete the other requests that do not relate to that controller, then log and shutdown the server. You will need several instances of sails running to avoid zero downtime, but that is material for another question. What you asked is how to get uncaught exceptions at a higher lvl than the controllers.
I suggest you read the node guide for error handling
Also read about domains, even thought they are deprecated you can use them, but you would have to deal with them per controller action, since sails does not provide any help with that.
I hope it helps.
You can check this way if you want to:
if (object != null && object.response != null && object.response.docs != null){
//Do your stuff here with your document
}
I don't really get what is your "object" variable in the first place, so i don't know if you can check it at a different level, is it a sails parameter to your controller ?
So that's how I did it, thanks to Zagen's answer.
module.exports.bootstrap = function(cb) {
process.on('uncaughtException', function (err) {
//Handle your errors here
logger.fatal(err);
global.__current__.res.serverError();
})
cb();
};
I send a generic error 500 to the user if any uncaught exception is thrown, and I log the error to the fatal level. On that way, my server is still accessible 24/7 and I can monitor the logs at another level and trigger an alarm on a fatal error. I can then fix the exception that was thrown.