Is there any guideline to classify and describe errors that a program throws? I'm talking about errors that I define in the code.
I've read that error description should be as specific as possible, but I was looking for some more rigid guideline of good practices on the topic.
Any hint apprecciated.
Thanks.
I know that this question is marked with "language-agnostic", but it depends a lot on the langauge that you are using in that you should follow the patterns and practices most commonly used in that language (and therefore most familiar to developers).
For example, read Error Raising and Handling Guidelines (MSDN) for some Microsoft .Net exception handling guidelines. (which I've just noticed are actually out of date, for example it recommends inheriting from ApplicationException).
Related
I've seen a lot of code in Sitecore where Assert.IsNull is used before any logic;
e.g.
Database database = Factory.GetDatabase(itemUri.DatabaseName);
Assert.IsNotNull(database, itemUri.DatabaseName);
return database.GetItem(attribute);
Could someone help me understand why I would use this?
This topic isn't really specific to Sitecore, even though in this case the assert methods are within the Sitecore library.
In general, assertions are used to ensure your code is correct during development, and exception handling makes sure your code copes in unpredictable circumstances.
Take a look at these SO questions for some very good explanations.
When to use an assertion and when to use an exception
When to use assert() and when to use try catch?
Here's an article specifically about the use of Sitecore assertions:
http://briancaos.wordpress.com/2012/01/20/sitecore-diagnostics-assert-statements/
From reading revision N3242 of the c++11 draft, it appears that some components of the standard library's interfaces (notably threading and locking) depend on exception handling.
Since I do a lot of work with exceptions disabled, I am wondering which library components/features will be (practically or logically) unusable without exception handling enabled?
First of all (just as a reminder), disabling exceptions and RTTI are compiler specific extensions the Standard has no consideration for.
Since the Standard Library is usually tied to the compiler, it may be that your implementation of the Standard Library has been specifically designed to cope with this (and in particular, to cope with new returning null pointers instead of raising std::bad_alloc).
Therefore, what you ask for is non-sensical. Check the documentation of your own library for a complete list.
That being said, the Standard does guarantee that a number of operations will never throw. I don't know of any operation that swallows exceptions, I would suppose that most of them are actually safe to use as-is.
For example, all algorithms should be safe.
Still, once again, I can only recommend reading the documentation of your implementation.
This question is over one month old, and unanswered.
I am providing an answer which can be considered a community wiki, add to it as needed.
std::thread Section 30.2.2. Transitive. Abstraction implemented using native implementations.
std::mutex, std::recursive_mutex, std::timed_mutex, std::recursive_timed_mutex. Section 30.4.1, Intransitive if you supply your own exception free locking (via BasicLockable, Lockable, TimedLockable). Abstraction implemented using native implementations.
std::condition_variable Section 30.5. Transitive. Abstraction implemented using native implementations.
note: There will be more.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last month.
Improve this question
I am wondering... I have read about Go some time ago and I tried to program something in it. I seems quite interesting. But I have reached handling "exceptions" in this language. I have read about their approach and it seems reasonable. I would like to know what are the advantages of the standard exceptional approach over the Go's style? What are the pros and cons?
Edit To be straight: I do not want to make any holy war about exceptions. I just wonder if this style of handling errors has any advantages? What are actual advantages of this style over standard exceptions? Is it worth wondering at all?
panic/recover is moral equivalent of try/catch exceptions. There is superficial difference (syntax) and a subtle, but important, difference of intended use.
The best explanations of problems with exceptions in general is "Cleaner, more elegant, wrong" and that's a good overview of pros/cons of exceptions vs. returning error codes.
Go designers decided that error handling by returning error codes from functions is the idiomatic Go way and the language supports multiple return values to make it syntactically easy. While panic/recover is provided, the difference is not of functionality but intended use.
Other languages exposing exceptions promote their use and in practice they are used frequently (sometimes even misused).
Go discourages the use of panic/recover. You can do it but you're only supposed to do it in very limited scenarios.
If you look at Go's own standard library, most uses of panic are for signaling fatal errors, indicating either an internal error (i.e. bug) in the library code or calling the library with wrong data (e.g. passing non-json data to json decoding functions).
But as the article you linked to points out: "The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values."
This is different from languages like C#, Java, Python or C++, where a lot of standard library code can throw exceptions to signal errors. Those languages want you to use exceptions. Go discourages the use of panic/recover.
To summarize:
idiomatic Go style is to use error codes to tell the caller about errors
use panic/recover only in rare cases:
to "crash" your program when encountering internal inconsistency indicating bugs in your code. It's basically a debugging aid.
if it dramatically simplifies error handling in your code (but if the code is to be used by others, never expose such panics to callers)
In practice the important thing is to use language's idiomatic style. In Go that's returning error codes and avoiding panic/recover. In C# that's using exceptions to signal some of the errors.
The ability to model the idea of catching an exception is pretty easy in a UML activity diagram - but what about THROWING the exception? The closest thing I can seem to find would be the throwing activity sending a signal with a stereotype of <<exception>> and then hitting a flow-final node, but I don't know that this is considered best-practice. Any thoughts?
Thanks.
UML 2.4 superstructure specification, in chapter 12.3.44 Pin (from BasicActivities, CompleteActivities), on figure 12.122 (page 416), you can see output pin for throwing exceptions. There is also an example on figure 12.129 (page 419).
UML notation exists to show exceptions.
Look at Larman's book:
Applying UML and Patterns: An
Introduction to Object-Oriented
Analysis and Design and Iterative
Development, Third Edition By Craig
Larman 35.3. Handling Failure Chapter
Larman says that :
*In summary, UML notation exists to
show exceptions. However, it is rarely
used. *This is not a recommendation to
avoid early consideration of exception
handling.* Quite the opposite: At an
architectural level, the basic
patterns, policies, and collaborations
for exception handling need to be
established early, because it is
awkward to insert exception handling
as an afterthought. However, the
low-level design of handling
particular exceptions is felt by many
developers to be most appropriately
decided during programming or via less
detailed design descriptions, rather
than via detailed UML diagrams.*
Usually the throwing an exception is displayed in the sequence diagram. I would say the following example is mainly used with Java but don't really know if it could also corespond to higher level of abstraction !!
Background
The book The Joy of Clojure explains how JVM exceptions are a closed system and suggests that there may be better alternatives for reporting and handling errors in clojure. From my experience, the common lisp condition system seems ideal, however, I am not restricting answers to this paradigm. From what I've researched there are conditions (Gilardi) http://clojure.github.com/clojure-contrib/condition-api.html , error-kit (Chouser) http://richhickey.github.com/clojure-contrib/error-kit-api.html, and handler (Weiss) https://gist.github.com/745223, however there does not appear to be a clear winner among these implementations and I feel more information on topic would be useful.
How have existing alternatives been successfully used in projects? I'm looking for examples to emulate.
How do these alternative systems overcome limitations with the JVM exception system?
What are the future directions or what are experimental alternatives on the horizon and what they entail?
FYI, this is being discussed in clojure-dev. Ideas collecting here and thread here.
Many years have passed since the question was asked, but I think the topic is still relevant. I have been working on Promenade (see documentation) that can express error as data and provides elegant error handling and control flow. There are also other projects (mentioned on Promenade README) trying to address the same issue.