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.
Related
I have tried many things but the only way I can force AzFn to understand the invocation has failed, is to throw an exception and not handle it. So, if I return an HttpResponseException, AzFn will consider the invocation as a success. That feels wrong.
catch (Exception ex)
{
logger.Error($"{nameof(ex)}: {ex.Message}", ex);
response = req.CreateErrorResponse(HttpStatusCode.InternalServerError, ex.Message, ex);
}
This should produce an invocation marked as fail but it doesn't.
Any exception thrown from your function will mark the function as failed. In your code above you're swallowing the exception, so we consider it successful. If you instead rethrow the exception, the function will be marked as failed. We'll automatically return a 500 in such cases on your behalf.
We don't look at the HttpStatusCode you return to determine if the function is successful, only whether the function ran successfully to completion w/o exception. If your function is able to return a response, it is successful from our point of view.
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.
I wrote a library with a number of async functions.
A SYNCHRONOUS helper function throws an error if one of the parameters is plain wrong:
proto.makeParameters= function( filters ){
default:
throw( new Error("Field type unknown: " + fieldObject.type ) );
break;
}
In my async functions, when I use it, I have:
proto.someAsyncFunction = function( cb ){
// Run the query
try {
var parameters = this.makeParameters( filters );
} catch( e ){
return cb( e );
}
}
So:
Is it good practice that asyncfunctions should never ever throw? (Like I did)
Right now, I am catching ALL errors. Shall I e more choosy? Maybe make up an error type and just check for that? If so, what should I do in either case?
Your assumptions on the async code are correct. See this post by Isaac Schlueter himself on the topic:
The pattern in node is that sync methods throw, and async methods pass
the error as the first argument to the callback. If the first
argument to your callback is falsey (usually null or undefined), then
all is well with the world.
http://groups.google.com/forum/#!msg/nodejs/W9UVJCKcJ7Q/rzseRbourCUJ
Is it good practice that async functions should never ever throw? (Like I did)
async functions, of course, will throw exceptions whenever we like it not, simply because of the software imperfection. So throwing custom exception is completely fine but what is important is how to correctly catch them.
The problem is that differently from sync code the stack of the async exception may not be available. So when the exception occurs, it is not always possible to say where to return the control and where is the handler. node.js has two methods of specifying what to do when the exception in asynchronous code occurs: process uncaughtException and domains.
As you see, dealing of the exceptions in async code is tricky so throwing an exception should be considered as a last option. If the function just returns status of the operation it is not an exception.
It seems for me that in the provided code fragment the exception is thrown correctly because it indicates that the method was called improperly and cannot do its job. In other words, the error is permanent. This indicates serious flaw in the application that should be fixed. But if the function cannot create a parameter for some temporary reason that can be fixed without modifying the application, then returning the status is more appropriate choice.
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'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.