I have my own exception in my application. And the moment I throw it like this:
throw new CChristianLifeMinistryEntryException(strError);
Understandably code analysis triggers this because I have used new.
It is suggesting that I use make_unique and I am trying to establish if that is the correct way to update this code.
In C++ exceptions are normally derived from std::exception and are thrown by value, and caught by reference. This way you don't need to manage lifetime (don't need to delete some exceptions after handling and not delete others).
Like throw std::runtime_error(str_error);.
MFC's approach of throwing reference with new predates C++ compiler exception support, so there was a way to throw a pointer exception, but not arbitrary type of exception. It is not recommended for the new code.
There's special smart pointer for exceptions called exception_ptr, it is usually needed to transfer exceptions between threads, not to wrap exceptions being thrown.
If you wrap an exception with unique_ptr, you'll have to catch it wrapped, and this catch will not catch derived exception, because different unique_ptr and not derived from each other, so wrapping exceptions this way is definitely not a good idea.
Related
I have a function that processes an image whose path is given by the user. I'm a bit new to Mathematica, and I can't find much on its large documentation. How can I throw an exception when Import[myFile] fails? Can I even do that?
Thanks a lot.
A simple prototype is
Catch[
Check[img = Import["myFile"], Throw[$Failed], Import::nffil];
Print["Processing image"]
]
Where you can make the Catch and Throw more targeted by using tags if need be.
You can use Throw[anyExpression] or Throw[anyExpression, exceptionTag] to throw an exception, with any expression. You can then use Catch[your code] or Catch[yourCode,exceptionPattern]. Exceptions in Mathematica are not objects like in e.g. Java, so you can not directly use the technique of building exception inheritance hierarchies and use multiple catch statements to catch from more specific to more general. Exception tags are needed to give an exception an identity, somewhat similar to exception class name in Java. Throw without a second argument will throw an untagged exception, which can be caught by Catch without a second argument. If you seriously want to use exceptions in Mathematica, I would advice against such usage, since you can easily catch something you did not plan to catch - just as you wouldn't normally use Exception in Java, but would rather subclass it. There are no checked exceptions in Mathematica, so all Mathematica exceptions can be considered run-time exceptions. Since the second argument of Catch is a pattern, you can construct Catch commands that would be able to catch exceptions with different tags, somewhat emulating the exception inheritance hierarchies of Java. The syntax is also different - there is no try - you just wrap Catch around a piece of code from where you may expect an exception. Note that Catch with no second argument won't catch a tagged exception, while Catch with the second argument won't catch an untagged exception. If you want both, you may need to nest like Catch[Catch[code,pattern]]. There is no finally clause provided as a built-in, but one may emulate it with a user-defined code, since in Mathematica one can program the control flow constructs as well, using non-strandard evaluation (functions with Hold-attributes etc). You can look for use cases of Catch and Throw in the documentation, here on SO posts,and on MathGroup, and you will find plenty o good examples.
HTH
Should I wrap every exception in a more meaningful exception? Wrapping meaning make the exception an inner exception of a new exception, and throw the "new" exception.
What factors do I need to think of when doing so?
Is the idea of wrapping exceptions because:
SQL Server could throw a bunch of exceptions from the T-SQL level. My C# API will only handle SQLException (handle meaning have a catch block for), so I'd want to wrap exceptions into a type my API can handle. This is just an example, SQL Server only throws SQLException, but is the concept right?
I assume that throwing the "new" exception, like mentioned above, would hold a cause which is not the real cause (which the dev needs to know), so would be more friendly for the end-user and hide sensitive implementation details of the real/first exception.
Thanks
You are on the right track. It is a good practice to wrap exceptions when they are crossing application layer boundaries. The below two posts are good reads on best practices
From MSDN
Java specific
It is quite tiresome writing try/catches in every method block.
Apart from AOP, is there any way to avoid this and catch all exceptions? Would it be enough to just catch them at the global error handler level (e.g. as in ASP.NET).
Thanks
The best advice I've heard on the subject (somewhere on SO, actually) was "only catch an exception if you're going to handle it." That is, it only makes sense to use a catch block in that method if that method has the means of handling the exception. For example, if the method should for some reason always return a value, and the exception is either silently logged or somehow indicated in the value (such as an error message attached to some custom DTO or something). There's nothing wrong with bubbling the exception upward in the stack and assuming the caller will handle it.
That's not to say, of course, that it shouldn't be handled at all. As you suggest, the last line of defense should always be the global exception handling for the application. All fails should be handled gracefully, but they should more importantly be handled only by the class/method that is supposed to handle them, which in many cases is not the method from which the exception originated. For example, in a simple forms over data web app, the data access doesn't necessarily need to handle the exception. It can add information to it if pertinent, but for such a simple app the global error handler can take care of logging and presenting an error message.
It should also be noted (I'm assuming you're talking about .NET here) that a try block need not always be accompanied by a catch block. You can try{}finally{} to take care of cleaning up after an exception (such as gracefully closing an external resource) without bothering to catch the exception and instead let it bubble up accordingly.
I agree with David. Here's my basic set of rules, or ... like the pirate code, guidelines ...
There should always be one global exception handler to catch runtimes and anything else that the classes cannot handle.
Try/catch should only be implemented when you can actually do something about the exception. And No, logging the exception is not doing something about it.
Adding a throws or Throwing a Exception or RuntimeException should be avoided. If you have a wide or large number of exceptions to deal with, create a new exception class to wrap them. Exception is too general and creates problems for other developers.
Try/catch blocks are expensive, do don't put them in unless necessary.
Never, and I mean NEVER !!! use try/catch for logic flow.
I've found it helpful to think of your code as having three layers, and using an exception strategy appropriate to each layer. I wrote up the details in Exceptions in the Rainforest.
Why is it a "bad idea" to throw your own exceptions?
found here
In general, it is perfectly fine to throw your own exceptions. Perhaps what you meant to ask was "When is it not necessarily a good idea to throw my own exception?"
One case is when you should be throwing a standard exception. For example, if your method takes a file name and is supposed to return a file, you should probably throw your platform's standard FileNotFoundException rather than throw PeanutPowersFileNotFoundException. If you really want to throw your own exception, you should probably have it extend the standard FileNotFoundException.
Update: Bloch explains this in Item 60 of Effective Java
It's not. You should create and throw custom exceptions whenever you have an exceptional situation.
It isn't provided they are derived from whatever the standard base exception type is (std::exception in c++, or Exception in python, etc...)
If they _aren't_derived from the normal base type, then other people may not catch them when they are expecting to catch all exceptions - which would be a bad thing.
It's not wrong to create your own exception type. However, before going through creating your own, you should check whether your framework already provides an exception that fits.
From the .Net design guidelines:
Consider throwing existing exceptions
residing in the System namespaces
instead of creating custom exception
types.
Do create and throw custom exceptions
if you have an error condition that
can be programmatically handled in a
different way than any other existing
exceptions. Otherwise, throw one of
the existing exceptions.
Do not create and throw new exceptions
just to have your team's exception.
I believe you might be asking why is it a bad idea to re-throw exceptions.
By "rethrow", I mean catching an exception and than generating a new one and throwing it. This can be problematic, as you could end up consuming the original stack trace and loosing all context of the error.
You should not invent your own type of Exception, unless you have something extra you want to add to the Exception type.
If you want to tell the user of your API that they have provided an invalid argument, you should throw an ArgumentException, but if your library fails because of some library specific reason, that you can't convey in a regular exception, you should roll your own and let it contain the info the developer needs.
To continue Peter's response another case when throwing an exception is not a good idea is if you use throwing exceptions to control the business logic of your program.
As long as the exception you are throwing is derived from a proper object, and conveys just that - exceptional situation, throwing an exception is totally acceptable.
Using throwing exceptions to control business logic in addition to being a bad design pattern has also performance implications - throwing and catching exceptions is rather expensive as compared to branching based on the results returned from the method
There's nothing wrong with creating your own exceptions, which can be tailored to convey exactly the information which is appropriate for your situation. A ConfigFileNotFoundException conveys more information than a FileNotFoundException (which file didn't we find?).
But, by all means, make sure that you catch and handle each and every custom exception inside of your code. When the exception flies to some place outside your module (call it package, call it namespace), those folks out there will not even know that it exists, much less what to do with it. Except for a catch (Throwable t) {/* whut? */}.
To me it seems that the question is to catch inexperienced candidates trying to fake experience. There's nothing wrong about throwing your own exceptions in my opinion, and as you can see to everyone else that answered here.
It's not a bad idea at all. If an exceptional situation arises, an exception should be thrown to handle it, especially if you're designing code that others may use, may receive bad input, etc.
It is a bad idea to use exceptions where they're not absolutely necessary, such as situations that are recoverable by normal checks in code or as part of normal execution, since they do have a lot of overhead associated with them. I imagine that's where you may have gotten the idea that they're a bad idea in general. But for what they're meant to do (flagging an exceptional situation that your code isn't equipped to handle), they're absolutely the best tool.
And if you do create custom exceptions for code others might use, do document what they are and what they mean. That way later users of your code will know that they're possible and what they mean if they arise, and can handle them appropriately.
I've seen the following code many times:
try
{
... // some code
}
catch (Exception ex)
{
... // Do something
throw new CustomException(ex);
// or
// throw;
// or
// throw ex;
}
Can you please explain the purpose of re-throwing an exception? Is it following a pattern/best practice in exception handling? (I've read somewhere that it's called "Caller Inform" pattern?)
Rethrowing the same exception is useful if you want to, say, log the exception, but not handle it.
Throwing a new exception that wraps the caught exception is good for abstraction. e.g., your library uses a third-party library that throws an exception that the clients of your library shouldn't know about. In that case, you wrap it into an exception type more native to your library, and throw that instead.
Actually there is a difference between
throw new CustomException(ex);
and
throw;
The second will preserve the stack information.
But sometimes you want to make the Exception more "friendly" to your application domain, instead of letting the DatabaseException reach your GUI, you'll raise your custom exception which contains the original exception.
For instance:
try
{
}
catch (SqlException ex)
{
switch (ex.Number) {
case 17:
case 4060:
case 18456:
throw new InvalidDatabaseConnectionException("The database does not exists or cannot be reached using the supplied connection settings.", ex);
case 547:
throw new CouldNotDeleteException("There is a another object still using this object, therefore it cannot be deleted.", ex);
default:
throw new UnexpectedDatabaseErrorException("There was an unexpected error from the database.", ex);
}
}
Sometimes you want to hide the implementation details of a method or improve
the level of abstraction of a problem so that it’s more meaningful to the caller
of a method. To do this, you can intercept the original exception and substitute
a custom exception that’s better suited for explaining the problem.
Take for example a method that loads the requested user’s details from a text file. The method assumes that a text file exists named with the user’s ID and a suffix of “.data”. When that file doesn’t actually exist, it doesn’t make much sense to throw a FileNotFoundException because the fact that each user’s details are stored in a text file is an implementation detail internal to the method. So this method could instead wrap the original exception in a custom exception with an explanatory message.
Unlike the code you're shown, best practice is that the original exception should be kept by loading it as the InnerException property of your new exception. This means that a developer can still analyze the underlying problem if necessary.
When you're creating a custom exception, here's a useful checklist:
• Find a good name that conveys why the exception was thrown and make sure that the name ends with the word “Exception”.
• Ensure that you implement the three standard exception constructors.
• Ensure that you mark your exception with the Serializable attribute.
• Ensure that you implement the deserialization constructor.
• Add any custom exception properties that might help developers to understand and handle your exception better.
• If you add any custom properties, make sure that you implement and override GetObjectData to serialize your custom properties.
• If you add any custom properties, override the Message property so that you can add your properties to the standard exception message.
• Remember to attach the original exception using the InnerException property of your custom exception.
You typically catch and re-throw for one of two reasons, depending on where the code sits architecturally within an application.
At the core of an application you typically catch and re-throw to translate an exception into something more meaningful. For example if you're writing a data access layer and using custom error codes with SQL Server, you might translate SqlException into things like ObjectNotFoundException. This is useful because (a) it makes it easier for callers to handle specific types of exception, and (b) because it prevents implementation details of that layer such as the fact you're using SQL Server for persistence leaking into other layers, which allows you to change things in the future more easily.
At boundaries of applications it's common to catch and re-throw without translating an exception so that you can log details of it, aiding in debugging and diagnosing live issues. Ideally you want to publish error somewhere that the operations team can easily monitor (e.g. the event log) as well as somewhere that gives context around where the exception happened in the control flow for developers (typically tracing).
I can think of the following reasons:
Keeping the set of thrown exception types fixed, as part of the API, so that the callers only have to worry about the fixed set of exceptions. In Java, you are practically forced to do that, because of the checked exceptions mechanism.
Adding some context information to the exception. For example, instead of letting the bare "record not found" pass through from the DB, you might want to catch it and add "... while processing order no XXX, looking for product YYY".
Doing some cleanup - closing files, rolling back transactions, freeing some handles.
Generally the "Do Something" either involves better explaining the exception (For instance, wrapping it in another exception), or tracing information through a certain source.
Another possibility is if the exception type is not enough information to know if an exception needs to be caught, in which case catching it an examining it will provide more information.
This is not to say that method is used for purely good reasons, many times it is used when a developer thinks tracing information may be needed at some future point, in which case you get try {} catch {throw;} style, which is not helpful at all.
I think it depends on what you are trying to do with the exception.
One good reason would be to log the error first in the catch, and then throw it up to the UI to generate a friendly error message with the option to see a more "advanced/detailed" view of the error, which contains the original error.
Another approach is a "retry" approach, e.g., an error count is kept, and after a certain amount of retries that's the only time the error is sent up the stack (this is sometimes done for database access for database calls that timeout, or in accessing web services over slow networks).
There will be a bunch of other reasons to do it though.
FYI, this is a related question about each type of re-throw:
Performance Considerations for throwing Exceptions
My question focuses on "Why" we re-throw exceptions and its usage in application exception handling strategy.
Until I started using the EntLib ExceptionBlock, I was using them to log errors before throwing them. Kind of nasty when you think I could have handled them at that point, but at the time it was better to have them fail nastily in UAT (after logging them) rather than cover a flow-on bug.
The application will most probably be catching those re-thrown exceptions higher up the call stack and so re-throwing them allows that higher up handler to intercept and process them as appropriate. It is quite common for application to have a top-level exception handler that logs or reports the expections.
Another alternative is that the coder was lazy and instead of catching just the set of exceptions they want to handle they have caught everything and then re-thrown only the ones they cannot actually handle.
As Rafal mentioned, sometimes this is done to convert a checked exception to an unchecked exception, or to a checked exception that's more suitable for an API. There is an example here:
http://radio-weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
If you look at exceptions as on an alternative way to get a method result, then re-throwing an exception is like wrapping your result into some other object.
And this is a common operation in a non-exceptional world. Usually this happens on a border of two application layers - when a function from layer B calls a function from layer C, it transforms C's result into B's internal form.
A -- calls --> B -- calls --> C
If it doesn't, then at the layer A which calls the layer B there will be a full set of JDK exceptions to handle. :-)
As also the accepted answer points out, layer A might not even be aware of C's exception.
Example
Layer A, servlet: retrieves an image and it's meta information
Layer B, JPEG library: collects available DCIM tags to parse a JPEG file
Layer C, a simple DB: a class reading string records from a random access file. Some bytes are broken, so it throws an exception saying "can't read UTF-8 string for record 'bibliographicCitation'".
So A won't understand the meaning of 'bibliographicCitation'. So B should translate this exception for A into TagsReadingException which wraps the original.
THE MAIN REASON of re-throwing exceptions is to leave Call Stack untouched, so you can get more complete picture of what happens and calls sequence.