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.
Related
At first I was excited about working on open development projects for Octave related to implementing programs heavy in mathematics and physics, such as delaunayTriangulation class, but after talking to a few octave maintainers I have come to the sad conclusion that Octave will be complete after classdef is complete, at which point physics or mathematician like programmers will no longer be needed to build new functionality to Octave. Is this true?
I have followed your thread on the Octave maintainers mailing list and I think you have misunderstood this quite badly.
Once classdef gets implemented, the problems won't be solved, quite the contrary. It will allow for many problems to be solved, which can't be done just yet in a Matlab compatible way. There are 2 things here:
you may have felt that there's no problems left to solve after seeing many suggestions of libraries that already solve the problem. That doesn't mean they will be used. Even if licensing allows it, there comes a point where having to "reshape" the data in Octave into whatever form the other library uses it, is just too much and a native interface is preferred. This is specially true in Octave because it's mostly written in the Octave language which allows for users to participate in its development.
Even if an external library is used in the end, remember that "the devil is in the details". Implementing an interface between Octave and an external library is not a trivial problem.
When classdef is complete, the work will start, not finish. And classdef is already working on the development version, so if you are interested in those classes, you could start implementing them there and they'd be released with the next version. To continue development of classdef, Octave needs that people it, so that it's problems can be found. And the delaunayTriangulation class requires classdef. It looks like a great pair, that should be developed together.
I saw this tutorial for writing a JSON-RPC server for SWI-Prolog. Unfortunately, all it does is add two numbers. I'm wondering if there exists a RPC server for SWI-Prolog that can define new rules and answer general Prolog queries, returning JSON lists, etc?
When you take a tour on SWI-Prolog website, proudly self-powered, you can see at work some of the features offered by http package.
It's a fairly large range of tools, and to grasp the basic of the system, the easiest way it's to follow the specific How to section, step by step. There is a small bug you should be aware in the LOD Crawler: add an option on line 42 of lod.pl:
...
; rdf_load(URI2, [format(xml)]),
....
or you will probably get
Internal server error
Domain error: content_type' expected, found text/xml;charset=UTF-8'
when running the sample.
An important feature of the IDE it's the ability to debug the HTTP requests.
When done with the HowTo, you can take a look to Cliopatria, dedicated to interfacing RDF to HTML. It come with a pirates demo, I must say I find it a bit too 'crude' for my taste, and I don't know about YUI, used in the award winning MultimediaN project. Then I've used Bootstrap to gain a modern look for the front end, with appreciable result (I'm sorry I can't - yet - publish it, need more time to engineering the system).
HTH
Back in my (limited) java programming days, I remember this nice feature where if I tried to make a call that could throw an exception, java would require me to handle that exception or pass it off to something that could.
Anyways, I am writing a piece of powershell code that messes around with objects in Active Directory, so I want to be very, very careful. I've gotten occasional remote timeout errors, and that is leading me toward the more general question:
"How can I know ahead of time which of these cmdlets can throw exceptions indicating dangerous conditions, and what is the list of those possible exceptions?"
I am wondering if the list of exceptions, per cmdlet, is way too long to address all possibilities. I also don't want to just write a generic exception handler, as powershell seems to do OK in the general sense of error handling.
What's the best way to determine, per cmdlet, the list of all exceptions that can occur? Is this even possible / feasible?
Thanks!
Heh, I think you started out on the wrong foot there. The jury is very much out on whether Java's checked exceptions are a nice idea.
That said, what you ask is very difficult to answer. In Java, it's clear to the compiler through static analysis what methods throw (or at least what they declare they will throw) what exceptions; this is a closed system existing solely in the process space of the compiler. In the real world of distributed heterogeneous systems, there is no universal checked exception framework. PowerShell cmdlets exist in the domain of a .NET appdomain in a win32 process, but they talk to backing systems on foreign servers using obtuse protocols like Active Directory which are a world apart both in implementation and general conception. Exceptional conditions may "flow" from one domain to the next, but they get warped, wrapped and mushed in all directions before they bubble up to you, the poor user at the console. In short, the answer is no. The general purpose Cmdlets (get-item, get-childitem) do not know about the underlying provider system's propensity to cause errors, and nor can they reliably know this.
However, if you have a dedicated module for Active Directory (like ActiveDirectory module from Microsoft, or Quest's QAD module) then it's possible they have listed the exceptions that their cmdlets will surface in the case of exceptional conditions in the backing system. This help would be found - most likely - in the module (or snapin) help files, or on a per-cmdlet basis. Try running the following command:
ps> get-help do-something -full | more
This will show the full invocation syntax along with any notes the developers have felt good enough to bless you with. Pay particular attention to the footer; it's here you'll usually find a more general help topic like "about_thesecmdlets" that you may view with: get-help about_thesecmdlets
Hope this helps.
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.
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).