The session.execute() portion of my Cassandra client does not prompt any error handling prompt in eclipse.
session.execute(batch);
Should I manually do try catch .
try
{
session.execute(batch);
}
catch(Exception e)
{
// Handle error here
}
If yes, Should I handle each error related to query execution separately?
NoHostAvailableException, QueryExecutionException, QueryValidationException, and UnsupportedFeatureException all extend DriverException which is a RuntimeException which is an unchecked exception. From the javadoc for RuntimeException:
RuntimeException and its subclasses are unchecked exceptions. Unchecked exceptions do not need to be declared in a method or constructor's throws clause if they can be thrown by the execution of the method or constructor and propagate outside the method or constructor boundary.
This is why eclipse doesn't give you a compiler error when you don't handle session.execute with a try catch or throws declaration in your method signature.
Related
When calling we'd like to be able to catch any exceptions in a try catch and hand over to our handler.
IVaultClient vaultClient = new VaultClient(vaultClientSettings);
try {
vaultClient.V1.Auth.PerformImmediateLogin();
} catch ( Exception e) {
}
Yes, in general, all VaultSharp APIs tend to throw this custom exception.
VaultApiException
See here for the fields.
https://github.com/rajanadar/VaultSharp/blob/master/src/VaultSharp/Core/VaultApiException.cs
However, the PerformImmediateLogin can also throw the Exception type when the HTTP login call to Vault does succeed but the response has an empty AuthInfo object (thus not giving back a vault token). This may or may not happen in real life, but this is the only case where Exception is thrown. Otherwise, you can always expect VaultSharp to throw the VaultApiException type.
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.
I am learning ANTLR4 and I have no previous experience with parser generators.
When I define my own visitor implementation, I have to override methods of the BaseVisitor (I am looking for instance at the EvalVisitor class at page 40 of the book). In case my method implementation possibly throws an exception, what should I do? I cannot use a checked exception since the original method has an empty throws clause. Am I expected to use unchecked exceptions? (this seems a bad Java design). For instance, assume that in the EvalVisitor class I want method visitId (page 41) to throw a user-defined exception, say UndefinedId, rather than returning 0. How should I write my code?
You have two options:
Handle the exception inside the visitor method itself.
Wrap your checked exception in an unchecked exception. One possibility is ParseCancellationException, but you'll have to determine for yourself whether or not that makes sense in your application.
try {
...
} catch (IOException ex) {
throw new ParseCancellationException(ex);
}
I'm getting this exception: Default constructor cannot handle exception type JAXBException thrown by implicit super constructor. Must define an explicit constructor
JAXBContext.newInstance throws a checked exception. You won't be able to directly set this on a field. You will need to move it inside your constructor and surround it with a try/catch block.
I've a list of records retrieved through external web service. Some of the data are rubbish and would like to log the record that failed by throwing a new exception.
Wondering if this is best way to handle, as i read exception can impact the performance?
Pseudo code e.g.
try
Loop through listOfRecords
perform logic.
catch
throw new exception (record details)
It depends on what you want to do with the rest of the records when an exception is encountered. Your current implementation would terminate the loop on the first error.
If, however, you simply want to mark the record in some way as "unprocessed" or "errored" and continue with the remaining records, you'd want to handle the error entirely within the loop:
foreach (var record in records)
{
try
{
Process(record);
}
catch (TypedException ex)
{
LogError(ex);
MarkAsUnprocessed(record, ex);
// respond in some other way as well?
}
}
Ultimately, the exception handling logic belongs wherever it logically makes sense to handle the exceptions. Catching exceptions is the easy part, that's a simple construct of the language being used. Meaningfully handling exceptions is another story entirely, and is a logical construct independent of the language being used.
Edit: It's also very much worth noting that your pseudo-code implies this way of handling exceptions:
try
{
// something
}
catch
{
throw new Exception("something");
}
This is very bad practice. Throwing an entirely new exception essentially tosses out the exception that was caught, which gets rid of some very useful debugging information (not the least of which being the stack trace). If you want to immediately log the exception and then let it continue up the stack, simply use the keyword throw by itself:
try
{
// something
}
catch (Exception ex)
{
// log the exception
throw;
}
If you want to add context to the exception, you can modify its properties before throwing it again. Or perhaps even better, throw a custom exception (not Exception) and attach the existing one as the InnerException property:
try
{
// something
}
catch (Exception ex)
{
throw new RecordProcessingException("some additional context", ex);
}
If, on the other hand, there's nothing meaningful to be done with the exception in the current context, don't even catch it at all. Let it bubble up the stack until it encounters code that can meaningfully handle it.
It's not the best way, since you only need the log-writing functionality. Just write to the log and continue the loop.