In Common Lisp (specifically SBCL in my case), it is common to define exceptions (known as "conditions") using the define-condition macro. This defines the condition globally, within the current package.
Is there a way to define a condition locally, within a specific scope? Or, alternatively, some other idiomatic way to prematurely exit a scope with a value, without polluting the global namespace?
(with-conditions
(block
(...)
(prematurely-exit-block-with some-data)
(...))
(when-condition-happens (some data) ...))
Is there a way to define a condition locally, within a specific scope?
No.
Or, alternatively, some other idiomatic way to prematurely exit a scope with a value, without polluting the global namespace?
Common Lisp has several constructs for such control flow, where one or more values are returned: RETURN, RETURN-FROM, THROW, ...
RETURN returns from a block named NIL
RETURN-FROM returns from a named block
THROW jumps to a catch tag, which got established via CATCH
return and return-from are using lexical blocks. catch establishes a dynamic scope for its tag.
Related
What is a simple technique to perform some action just once, no matter how many times the function is executed? Do any programming languages have specific ways built-in to handle this somewhat common problem?
Example: initialize() shall set global_variable to true on ONLY its first execution.
A c++ example (looking for alternatives to this out of curiosity - not necessity):
init.h:
int global_variable;
void initialize(void);
init.c:
static bool already_initialized = false;
void initialize(void)
{
if (!already_initialized)
{
already_initialized = true;
global_variable = true;
}
}
Apart from the global variable technique that's available in any language there are several other ways to do this.
In languages that have static variables using a static variable instead of global is preferable in order to prevent variable name collisions in the global scope.
In some languages you can redefine/redeclare functions at runtime so you can do something like this:
function initialize (void) {
// do some stuff...
function initialize(void) {}; // redefine function here to do nothing
}
In some languages you can't quite redeclare functions within functions due to scope issues (inner functions) but you can still reassign other functions to an existing function. So you can do something like this:
function initialize (void) {
// do some stuff ...
initialize = function (void) {}; // assign no-op anonymous function
// to this function
}
Some languages (especially declarative languages) actually have a "latch" functionality built in that executes just once. Sometimes there is even a reset functionality. So you can actually do something like this:
function do_once initialize (void) {
// do some stuff
}
If the language allows it you can reset the do_once directive if you really want to re-execute the function:
reset initialize;
initialize();
Note: The C-like syntax above are obviously pseudocode and don't represent any real language but the features described do exist in real languages. Also, programmers rarely encounter declarative languages apart from HTML, XML and CSS but Turing complete declarative languages do exist and are typically used for hardware design and the "do_once" feature typically compiles down to a D flip-flop or latch.
Eiffel has a built-in notion of once routines. A once routine is executed only the first time it is called, on the next call it is not executed. If the routine is a function, i.e. returns a result, the result of the first execution is returned for all subsequent calls. If the first call terminates with an exception, the same exception is raised for all subsequent calls.
The declaration of the once function foo looks like
foo: RETURN_TYPE
once
... -- Some code to initialize Result.
end
In a multithreaded environment it might be desirable to distinguish objects used by different threads. This is accomplished by adding the key "THREAD" to the declaration (it is actually the default):
foo: RETURN_TYPE
once ("THREAD")
...
end
If the same object has to be shared by all the threads, the key "PROCESS" is used instead:
foo: RETURN_TYPE
once ("PROCESS")
...
end
The same syntax though without return type is used for procedures.
Process-wide once routines are guaranteed to be executed just once for the whole process. Because race conditions are possible, Eiffel run-time makes sure at most one thread may trigger evaluation of the given once routine at a time. Other threads become suspended until the primary execution completes so that they can use the single result or be sure the action is performed only once.
In other respects once routines are no different from the regular routines in a sense that they follow the same rules of object-oriented programming like inheritance and redeclaration (overriding). Because this is a normal routine it can call other routines, directly or indirectly involving itself. When such a recursive call occurs, the once routine is not executed again, but the last known value of the result is returned instead.
yes, some languages (scala) does support it (using lazy) but usually this functionality is provided by frameworks because there are some trade offs. sometimes you need thread level, blocking synchronization. sometimes spin-offs is enough. sometimes you don't need synchronization because simple single-threaded cache is enough. sometimes you need to remember many calculated values and you are willing to forget last recently used ones. and so on. probably that's why languages generally don't support that pattern - that's frameworks' job
I am attempting to understand from where exception conditions derive. My question is at the end, but I will present an example that might make it clearer.
Take this Java code, for example. It has the path to a file and set-up a File object. If the path is null, an exception is thrown.
String path = getPathName();
try {
File file = new File(path);
} catch (NullPointerException e) {
// ...
}
This is hardly an exceptional circumstance, though, and if we could modify it in such a way that this might be preferrable:
String path = getPathName();
if (path == null) {
path = DEFAULT_PATH;
}
File file = new File(path); # we've removed the need for an exception
But moving further, we run into a new exception when we try and make the File readable.
try {
file.setReadable(true);
} catch (SecurityException e) {
// ...
}
We can skirt around this issue by checking two conditions:
SecurityManager sm = System.getSecurityManager();
if (sm != null && sm.checkWrite(path)) {
// modify the SecurityManager
} else {
file.setReadable(true);
}
With this example in mind, on to my question...
If we move down the stack, going from Java to the OS, etc., is it possible to replace all exception handling code with if-else branches? Or is there some root cause of exceptions (hardware?) that means they are "baked" into programming?
If we move down the stack, going from Java to the OS, etc., is it possible to replace all exception handling code with if-else branches?
Yes. This is how it used to be done, and still is in languages without exceptions. Exceptions are used because they are easier in a number of senses. The primary advantages are that cases not anticipated by the programmer can be aggregated in a general handler; and that information about the exceptional condition does not need to be explicitly preserved in every single function until it is properly handled.
Or is there some root cause of exceptions (hardware?) that means they are "baked" into programming?
Also yes. In general, unexpected hardware conditions need to be handled in some way, unless you are comfortable with undefined behaviour in such cases.
If all the methods in a program returned a pointer/reference to some kind of "exception" object (for other return values, pass in a pointer or reference to a caller-allocated storage location), and if every call to every method which might directly or indirectly want to throw an exception were bracketed with something like:
ret = callFunction( ...parameters...);
if (ret != NULL)
return AddToExceptionStacktrace(ret, ...info about this call site... );
then there would be no need for any other form of exception handling (note that if the type supports scoped variables, the "return" statement would have to insert code to clean them up before it actually returns to the caller).
Unfortunately, that's a lot of extra code. This approach would be workable in a language which had only "checked" exceptions (meaning a method can neither throw exceptions nor pass them through unless it is declared as doing so), but adding that overhead to every function which might directly or indirectly call a function which throws an exception would be very expensive. Exception-handling mechanisms generally eliminate 99% of the extra overhead in the no-exceptions case, and the expense of increasing the overhead in the "exception" case.
How can I avoid getting an error when passing as argument to the function do-http-request an invalid host.
Is there any way that I can catch the error like the Java's exception-handling mechanism ?
Sure, CL has a very nice condition system. One easy option would be wrapping the call to do-http-request in ignore-errors, which returns nil (and the condition as a second value) if an error condition was signalled in the wrapped code. You could then check for nil afterwards.
If you want something more like exception handling in Java, just use handler-case and add an appropriate error clause (I don't have AllegroServe installed, but I suppose you get a socket-error for providing a wrong URL – just change that part if I misread):
(handler-case
(do-http-request …)
(socket-error ()
…))
If you need finally-like functionality, use unwind-protect:
(unwind-protect
(handler-case
(do-http-request …)
(socket-error (condition) ; bind the signalled condition
…) ; code to run when a socket-error was signalled
(:no-error (value) ; bind the returned value
…)) ; code to run when no condition was signalled
…) ; cleanup code (finally)
You can even get more fancy, and e.g. use handler-bind to handle the condition stack upwards by invoking a restart somewhere down the stack, without unwinding it. For example, if do-http-request provided a restart to try again with another URL, you could handle your error condition by invoking that restart with a new URL to retry. I just mention this for the sake of completeness – it would be overkill for your use case, but being able to resume (possibly expensive) computations easily can be a rather convenient feature.
Interesting discussion came up among my peers as to whether or not the "if" statement is considered a method? Although "if" is appended with the word statement it still behaves similar to a simple non-return value method.
For example:
if(myValue) //myValue is the parameter passed in
{
//Execute
}
Likewise a method could perform the same operation:
public void MyMethod(myValue)
{
switch(myValue)
{
case true:
//Logic
break;
case false:
//Logic
break;
}
}
Is it accurate to call (consider) the "if" statement a simple predefined method in a programming language?
In languages such as C, C++, C#, Java, IF is a statement implemented as a reserved word, part of the core of the language. In programming languages of the LISP family (Scheme comes to mind) IF is an expression (meaning that it returns a value) and is implemented as a special form. On the other hand, in pure object-oriented languages such as Smalltalk, IF really is a method (more precisely: a message), typically implemented on the Boolean class or one of its subclasses.
Bottom line: the true nature of the conditional instruction IF depends on the programming language, and on the programming paradigm of that language.
No, the "if" statement is nothing like a method in C#. Consider the ways in which it is not like a method:
The entities in the containing block are in scope in the body of an "if". But a method does not get any access to the binding environment of its caller.
In many languages methods are members of something -- a type, probably. Statements are not members.
In languages with first-class methods, methods can be passed around as data. (In C#, by converting them to delegates.) "if" statements are not first-class.
and so on. The differences are myriad.
Now, it does make sense to think of some things as a kind of method, just not "if" statements. Many operators, for instance, are a lot like methods. There's very little conceptual difference between:
decimal x = y + z;
and
decimal x = Add(y, z);
And in fact if you disassemble an addition of two decimals in C#, you'll find that the generated code actually is a method call.
Some operators have unusual characteristics that make it hard to characterize them as methods though:
bool x = Y() && Z();
is different from
bool x = And(Y(), Z());
in a language that has eager evaluation of method arguments; in the first, Z() is not evaluated if Y() is false. In the second, both are evaluated.
Your creation of an "if" method rather begs the question; the implementation is more complicated than an "if" statement. Saying that you can emulate "if" with a switch is like saying that you can emulate a bicycle with a motorcycle; replacing something simple with something far more complex is not compelling. It would be more reasonable to point out that a switch is actually a fancy "if".
You can't create a myIfStatement() method and expect the following to work:
...
myIfStatement(something == somethingElse)
{
// execute if equal
}
else
{
// execute if different
}
if is a control statement, and cannot be replicated by a method, nor can you replace a method call with if:
myVariable = if(something == somethingElse);
if cannot be overloaded.
These are a few signs that if is not a method, but there are others I suspect.
Depends on the language for sure, but in C, java, perl, no, they're language commands. Reserved words. If they were functions, you'd be able to overload them and get pointers to them and do all the other things that you can do with functions.
This is more of a philiosophical question than a programming question though.
A method has a signature and its main intention is resuable logic, whereas if is simply a condition that controls the flow of execution.
If you understand assembly, you would know that both are different even on a very low level.
You can of course write If() and IfElse() methods but that does not make them the same.
if() is defined as a statement in the language , at the same level as method calls. But there are differences in a.o. syntax and optimization possibilities.
So: No, the if() statement is not a method. You cannot for instance not assign it to a delegate.
Considering the if statement to be a method only makes it confusing, in my opinion. The similarities with a method call is just superficial.
The if statement is one of the statements that control the execution flow. When it's compiled into native machine code, it will evaluate the expression and make a conditional jump.
Pseudo code:
load myValue, reg0
test reg0
jumpeq .skip
; code inside the if
.skip:
If you use else, you will get two jumps:
load myValue, reg0
test reg0
jumpeq .else
; code inside the if
jmp .done
.else:
; code inside the else
.done:
Is the “if” statement considered a method?
No, it's not considered a method as you may have already seen in the other answers. However, if your question were - "Does it behave like a method?", then the answer could be yes depending on the language in question. Any language that supports first-class functions could do without an in-built construct/statement like if. Ignore all the fluffy stuff like return values and syntax, as basically it is just a function that evaluates a boolean value and if it is true, then it executes some block of code. Also ignore OO and functional differences because the following examples can be implemented as a method on the Boolean class in whatever language is being used like Smalltalk does it.
Ruby supports blocks of executable code that can be stored in a variable and passed around to methods. So here's a custom _if_ function implemented in Ruby. The stuff within the { .. } is a piece of executable code that's passed to the function. It's also known as a block in Ruby.
def _if_ (condition)
condition && yield
end
# simple statement
_if_ (42 > 0) { print "42 is indeed greater than 0" }
# complicated statement
_if_ (2 + 3 == 5) {
_if_ (3 + 5 == 8) { puts "3 + 5 is 8" }
_if_ (5 + 8 == 13) { puts "5 + 8 is 13" }
}
We can do the same thing in C, C++, Objective-C, JavaScript, Python, LISP, and many other languages. Here's a JavaScript example.
function _if_(condition, code) {
condition && code();
}
_if_(42 > 0, function() { console.log("Yes!"); });
If it were to be classed as a method then surely we would be in the realms of OO, however we're not, so I'll assume we're on about a function. Certainly a function/subroutine could be written to replicate the if behaviour (I think it is actually a function in lisp/scheme).
I wouldn't class it as a function or even a subroutine though, just control flow.
If by method we understand a block of code that could be called and the control flow automatically returns to the caller when the method ends, then ifs aren't methods. The control flow doesn't return anywhere after an if is executed.
The IF statement is a conditional contruct feature used in most lanuages which executes a path flow from the boolean condition evaluation of true or false. Apart from the case of branch predication, this is always achieved by selectively altering the control flow based on some condition.
The IF construct is the most basic and needed logic used when programming. It allows the building blocks for functions to be introduced.
Yes, if is a function in certain languages, even though it's rare and the uses are limited.
Usually the construct is something like if(booleanCondition, functionPointerToCallIfConditionTrue, functionPointerToCallIfCondtionFalse) This can itself be used as a delegate to other functions if you want.
Mathematica, for example, behaves this way and even C# can do so with a bit of work if you use Linq-expressions; Take a look at System.Linq.Expressions.Expression.IfThenElse.
No. You don't return back when you are finished with an if. It's merely a control statement.
Note that in your example, you replaced one "selection statement" (C# 4 specification, section 8.7), the if statement (section 8.7.1) with another, the switch statement (section 8.7.2). You also refactored the selection statement into a separate method. You haven't replaced the use of a selection statement with a method, however.
The answer to your question is "no".
For example, in the case of "The array index out of bound" exception, why don't we check the array length in advance:
if(array.length < countNum)
{
//logic
}
else
{
//replace using exception
}
My question is, why choose to use an exception? and when to use an exception, instead of if-else
Thanks.
It depends on acceptable practices for a given language.
In Java, the convention is to always check conditions whenever possible and not to use exceptions for flow control. But, for example, in Python not only using exception in this manner is acceptable, but it is also a preferred practice.
They are used to inform the code that calls your code an exceptional condition occurred. Exceptions are more expensive than well formed if/else logic so you use them in exceptional circumstances such as reaching a condition in your code you cannot handle locally, or to support giving the caller of your code the choice of how to handle the error condition.
Usually if you find yourself throwing and catching exceptions in your own function or method, you can probably find a more efficient way of doing it.
There are many answers to that question. As a single example, from Java, when you are using multiple threads, sometimes you need to interrupt a thread, and the thread will see this when an InterruptedException is thrown.
Other times, you will be using an API that throws certain exceptions. You won't be able to avoid it. If the API throws, for example, an IOException, then you can catch it, or let it bubble up.
Here's an example where it would actually be better to use an exception instead of a conditional.
Say you had a list of 10,000 strings. Now, you only want those items which are integers. Now, you know that a very small number of them won't be integers (in string form). So should you check to see if every string is an integer before trying to convert them? Or should you just try to convert them and throw and catch an exception if you get one that isn't an integer? The second way is more efficient, but if they were mostly non-integers then it would be more efficient to use an if-statement.
Most of the time, however, you should not use exceptions if you can replace them with a conditional.
As someone has already said, 'Exceptions' in programming languages are for exceptional cases and not to set logical flow of your program. For example, in the case of given code snippet of your question, you have to see what the enclosing method's or function's intention is. Is checking array.length < countNum part of the business logic or not. If yes, then putting a pair of if/else there is the way to go. If that condition is not part of the business logic and the enclosing method's intention is something else, then write code for that something else and throw exception instead of going the if/else way. For example you develop an application for a school and in your application you have a method GetClassTopperGrades which is responsible for the business logic part which requires to return the highest marks of the student in a certain class. the method/function definition would be something like this:
int GetClassTopperGrades(string classID)
In this case the method's intention is to return the grades, for a valid class, which will always be a positive integer, according to the business logic of the application. Now if someone calls your method and passes a garbage string or null, what should it do? If should throw an exception e.g. ArgumentException or 'ArgumentNullException' because this was an exceptional case in this particular context. The method assumed that always a valid class ID will be passed and NULL or empty string is NOT a valid class ID (a deviation from the business logic).
Apart from that, in some conditions there is no prior knowledge about the outcome of a given code and no defined way to prevent an exceptional situation. For example, querying some remote database, if the network goes down, you don't have any other option there apart from throwing an exception. Would you check network connectivity before issuing every SQL query to the remote database?
There is strong and indisputable reason why to use exceptions - no matter of language. I strongly believe that decision about if to use exceptions or not have nothing to do with particular language used.
Using exceptions is universal method to notify other part of code that something wrong happened in kind of loosely coupled way. Let imagine that if you would like to handle some exceptional condition by using if.. nad else.. you need to insert into different part of your code some arbitrary variables and other stuff which probably would easily led to have spaghetti code soon after.
Let next imagine that you are using any external library/package and it's author decided to put in his/her code other arbitrary way to handle wrong states - it would force you to adjust to its way of dealing with it - for example you would need to check if particular methods returns true or false or whatever. Using exceptions makes handling errors much more easy - you just assume that if something goes wrong - the other code will throw exception, so you just wrap the code in try block and handle possible exception on your own way.