[JAVA-2129] Exception in callback is catched by async driver Created: 29/Feb/16 Updated: 11/Sep/19 Resolved: 28/Apr/16 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Async, Error Handling |
| Affects Version/s: | 3.2.2 |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Ben [X] | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Errors inside the SingleResultCallback are catched by the mongoDB async driver. For example, if your throwable parameter is null and you access it, you won't get an exception because the driver is catching the null pointer exception. For debugging this is not ideal. The Exception should be delegated to the developers scope. |
| Comments |
| Comment by Ross Lawley [ 28/Apr/16 ] |
|
|
| Comment by Ben [X] [ 19/Apr/16 ] |
|
mh I understand, that is really complicated. But a compromise would be show the logged error in admin web panel or send an email to a configured email address. I understand that it's not possible to let programmers handle exceptions inside of their callbacks. But an active notification that something went wrong would probably help. mh another idea is, to create a file listener, that listens to an "callback error" file. If something goes wrong, the error is written to that file and the main thread error listener would recognize it. But this solution sounds a little bit hacky. |
| Comment by Ross Lawley [ 18/Apr/16 ] |
|
Hi @ChampS, I fully understand it is a challenge and would like to be able to provide a simpler answer, if you have any ideas it would be good to hear them. The only way the driver can signal the users thread of the result of an operation is via the user provided callback, and its part of the contract that the provided callback must not throw an error. The reason for this is mentioned in my initial comment - the callback is executed on a different thread so it wouldn't be visible to the end user. The reason we catch and log thrown errors from the provided callback is because the alternative would be throwing the error on a connection pool thread and this would eventually poison the pool. If you want your developers to handle errors programmatically then you could, either use try catch blocks in the callback or DRY that logic up and write your own form of an ErrorHandlingCallback implementation and wrap provided callbacks - as you can see from the driver implementation it doesn't require much code. The other alternative would be writing defensive callbacks where any values from document.get are null checked before preceding and testing to ensure no errors are thrown. Regarding Logging, Information on the configuration can be found here: Logging Documentation. I would expect WARN level log messages to be defaulted to on. I hope that clarifies the reasoning why the driver can't throw errors generated from user provided callbacks. Ross |
| Comment by Ben [X] [ 18/Apr/16 ] |
|
Question: Is the default configuration to ignore these errors? Logging these errors is ok, but imho not enough. As an developer it's very problematically to recognize an error in this scenario. Most people look into log files if they notice an error or wrong behavior. Without an exception in their callback, mostly they won't notice. In worst case they will recognize an error when it's too late, because data is missing or something. For example they show monthly aggregated data in their gui but at the end of the month there is no data. This could be prevented at the beginning of the month, if they had recognized the error or handled it programmatically. That's another Point, you take away the possibility to handle errors programmatically by the developer. They have to look into the log file and solve the problem manually. |
| Comment by Ross Lawley [ 18/Apr/16 ] |
|
Just to clarify, we do log any errors that occur in this scenario. So depending on your application logging configuration these errors maybe be printed to stdout or logged to a file or ignored (not wise). |
| Comment by Ben [X] [ 02/Mar/16 ] |
|
If the user itself does not handle exceptions in his callback, the expectable behavior is imho print the stacktrace. Catch the exception inside the driver and hide it from the user, just complicates the debugging process I think. |
| Comment by Ross Lawley [ 29/Feb/16 ] |
|
This is "as designed". The context that is running the actual code is not the same as the one passing the callback to the function. Another thread will execute the user provided callback once the command or query has finished, either successfully or by throwing an error. The difficulty comes if the user callback itself generates an error - who can handle the error? Unfortunately, there is no callback available to tell the user that the error has happened. Because the provided callback itself errors! We handle this Internally by wrapping callbacks in an ErrorHandlingResultCallback which catches the error and then logs the error. This is a method of last resort as there is no other way to let the user know about the error. |