Thursday, 30 May 2013

Named Parameters in JavaScript

JavaScript does not support Named Parameters, but given how malleable the language is, there should be some way to achieve something similar (bearing in mind that eval and function.toString are so powerful functions that should make any C#/Java guy with an interest in Reflection cry with envy).
I got interested on this idea after glancing over this article that mentions that Angular.js sort of implements it.

Named parametes are mainly useful for functions with a long list of parameters, and the normal way to address this in javascript is using an options object (like for example $.ajax does). I mean:

//rather than: 
function sayHi(name, age, city, language){

function sayHi(options){

//and invoke it like this:
 city: "Prague", 
 age: 20,
 name: "Iyan"

the above solution seems good to me, but has 2 problems:

  • Now the code in your function will be like this:, options.age... rather than name, age...
  • What if you already have an existing function and want to enable named parameters in it?

Well, that's just what I've done. I've written a simple function enableNamedParameters that will receive a function and will return a new one that can be invoked with a "NamedParameters" object, or with a normal parameters list as in the original function.

Usage is like this:

function sayHi(name, age, city, language){
 console.log("hi, my name is: " + name 
 + " my age is: " + age
 + " I live in: " + city
 + " and my native language is: " + language);

var sayHi2 = enableNamedParameters(sayHi);

//using named parameters
 city: "Prague", 
 age: 20,
 name: "Iyan"

//using no named parameters
sayHi2("Iyan", 20, "Prague", "English");


You can find the code here.

Update: 2013/07/27 if you check the gist above you'll see it's been updated so that now a mix a unnamed and named parameters is supported. Named parameters (the NamedParameters object) must be supplied after unnamed parameters)

Thursday, 23 May 2013

Critical Exceptions

Last year I wrote a couple of posts [1] and [2] about exception handling and process crashes. I've learnt something new recently that somehow completes those previous posts, so here it goes.

For a new project on which I'm involved at work one of the requirements for the .Net based server side is that errors in certain parts of the system (let's call them plugins) should never bring down the whole process, let's call it "failure isolation". OK, .Net + units of isolation... Application Domains rapidly spring to mind. Well, such solution is wrong for this case.

With Application Domains you get quite a few things, like access isolation (code running in one Application Domain can run with restricted permissions), the chance to unload the Application Domain (and all its assemblies) from memory... but you don't get the kind of failure isolation we need here, as an Application Domain is not an "execution unit" like processes or threads. The code in the different Application Domains in your process is not associated to specific threads, one thread can run code in different Application Domains (it starts in one method, then call a method of an object residing in a different Application Domain... and so on). So an exception in an Application Domain will bubble up the thread's stack out of the Application Domain, that is, exceptions propagate through Application Domains, and an uncaught one will have effects beyond the Application Domain where it was thrown. This is so, even if we were running the code in that Application Domain in a new thread, cause as I already explained here an uncaught exception in any thread of a .Net application (not just in the main one) will bring down the whole process. To sum up, an unhandled exception in one Application Domain can crash the whole process.

OK, so in the end, regardless whether we need Application Domains or not for isolating groups of objects and granting different permissions and regardless whether we're creating new threads ... we'll need to make sure that any time we invoke code in those plugins we do it wrapped in a try-catch clause. Hum, it appears like the whole thing is much more simple than I firstly had reckoned. Well, this is not the case, as something so far unknown to me enters the scene: there are exceptions that can not be caught, they will just skip your catch block.

These exceptions are called Corrupted State Exceptions and are pretty well explained here. The CLR will mark certain exceptions as CSE ones (memory violations, stack overflows), and your normal catch blocks won't be able to catch them. You can test it easily by running something like this:

class Program
        static void ThrowCriticalException()
            int i = 0;
            Action ac = null;
            ac = () =>
                Console.WriteLine("call: " + i++);
        static void Main(string[] args)
            catch (Exception ex)
                Console.WriteLine("Exception caught");

            Console.WriteLine("Press key to exit");

Notice that if you were throwing the StackOverflow yourself by doing a throw new StackOverflowException();, that case could be caught, this is, as the article explains, because it's the system who will mark an exception as a CSE one, and if it finds that it's been thrown by the user, it won't consider it critical. Also from the article it would seem like decorating your method with the [HandleProcessCorruptedStateExceptions] attribute would allow you to catch it, but I've tested and it's still no possible.

We should realize that not being able to catch these exceptions is a feature rather than a limitation, cause a program where invalid memory accesses have happened should not be allowed to continue to run. Notice that using a generic catch(Exception ex) is mostly a dangerous practice.

By the way, that msdn article corroborates what I'd just said in the first paragraphs:

Exceptions raised on a thread of execution follow the thread through native and managed code, across AppDomains, and, if not handled by the program, are treated as unhandled exceptions by the operating system.

A single thread in one AppDomain can bring down an entire CLR instance by not handling an exception

Also, though this should be obvious I'll put it here for further reference, Application Domains have no effect on Garbage Collection, I mean, Garbage Collection works at the process level, going across Application Domains.

Monday, 13 May 2013

Rhino Season

Monica Bellucci performing in an Iranian-Turkish film by one "alternative" Iranian director seemed like an unusual combination worth a try. Wow, Rhino Season is a striking, beautifully painful film. It's more the kind of work I would expect to watch on the big screen in FIC Xixón, but has also made a perfect experience when watched on my laptop on a Saturday night.

The last decades of Iranian history have been bitterly harsh, and this film radiates all that pain with such a strength and efficiency. The Iranian Revolution should have served as a warning to all those that 2 years ago supported and praised the "Arab Spring" revolutions. I was completely certain that such revolutions would do much more harm than good to the decent people in those countries, replacing the corrupt westernized dictators by hordes of Islamist beasts. Sadly, my gloomy predictions have proved quite true, and we've seen the fucking Islamists raise to power and start to impose their demented ideas on the population of Egypt, Libya and to a lesser extent Tunisia... All those progressive Arabs (women, social activists...) that joined the Islamists in the revolts should have had a bare knowledge of recent history and a basic ability to apply it to the present, they should have known that in Iran in the late 70's the communists made common cause with the Islamists to overthrow the Shah, only to be paid later on by the Islamist with death sentences, torture and prison...

The film is set against the backdrop of Iranian "revolution", showing the miseries brought about not only by the enforcement of Islamic oppression on the population, but also by the raise to power of a new breed of corrupt and ignorant officials that will use their new powers in even more despotic ways than their predecessors, torturing, cheating, humiliating... It's a deeply emotional film, necessarily slow, as the calm pace is needed to let emotions sink. A story where love is the cause of so much pain... a healthy love on one side that can't manage to get over the misery created by another obsessive, sick and twisted love.

The peformance by Monica Bellucci's and the 2 main male characters are simply perfect, transmitting pain and desolation in each of their looks and moves, but it's the photography what will really stick with you for a long, long time. It's really striking, breathtaking in many occasions, dark, intense, violent...
Summing up, an indispensable film to be both enjoyed and suffered.

Thursday, 9 May 2013

Return to Sender

I've just watched this excellent film on TV. I'd taken a fast glimpse at the argument and it seemed it could be interesting, so when to my delight I found it was starred by the Scandinavian Goddess Connie Nielsen I felt compelled to remain glued to the screen for its entire length. Not only she's one of the most beautiful women on Earth, but she has also taken part on astonishing films like The Devil's Advocate (that antireligion speech by Al Pacino just at the end is one of the most memorable moments in the history of cinema/art), Demon Lover (an original plot with a great aesthetic) , Brothers...

As for this film itself, we'll see how an odd relationship develops between 2 lost, tortured souls (yes, I love films about fucked up people). On one side, one woman in the death corridor seeks for redemption through punishment and death after having killed a baby. On the other side, an ex-lawyer makes a living from befriending death sentenced people and reselling their letters to the papers... Well, put this way, both characters appear like real pieces of shit, but coming into contact will be a really life changing experience for both (and a really entertaining one for the viewer).

Monday, 6 May 2013


A couple of days ago I watched a really excellent Dutch documentary, Panopticon (hopefully it comes with English subtitles). The title really caught my attention (not just because it's also one album from one of my all times favourite bands, and a record from another band that I used to listen quite a lot), but because year after year the notion that our current "Big Brother society" is more and more like a Panopticon turns quite realistic. Well, indeed, in the Prison-Panopticon, the prisoner couldn't know if he was being observed at a given moment, but he knew for sure that there were no means to having him observed all the time, however, now we can have the certainty that our traces in Internet, or int the public transport and streets of many cities, are being stored forever... as they say in the documentary, if storage space has become so cheap that you no longer need to empty your mailbox, the same applies to all those other digital traces.

There are many interesting points in the documentary, but I won't touch on them, just watch it! but the point I'd like to note cause sounds so stupid to me, is the fact that many people don't seem to be concerned with all this "being observed/loss of privacy" thing, because they just "have nothing to hide". Seriously, that's such a poor reasoning... it's not whether you have things to hide because you've done something "bad" or punishable, the whole point is that some people (like me) feel like our life belongs to us, and don't want other people (specially strangers) to know what we feel/love/hate, what our normal activities are, we don't want others to be able to reconstruct what we'll be doing tomorrow based on our previous days. It's something purely subjective, some people can tell all their lives to others they've just met, while others are pretty more reserved and don't feel like talking about feelings/health whatever... Some people love small villages because of the feeling of community that maybe you can get there, others love big cities for the anonymity that they used to provide. In the end it's a bit like the right to private property, we all should have the right to own our basic stuff, but nobody should be allowed to own 10 million "basic stuffs". Same for privacy, we all should have the right to our "inner world", but admittedly there are spaces that should be allowed to be monitored for security reasons. It should not be that difficult to draw the line...

Privacy, yeah, repeat with me, privacy, privacy, privacy... yes, it used to be quite an important part of our understanding of freedom, but now it's something irrelevant to too many people, I guess some consider it old fashioned. Well, I've never been a cool guy, so probably not being willing to share parts of my life with strangers is a normal step in this path that has always kept me away from the funny, shiny, attractive people... It's not that I'm not such a loner as I usually try to pretend, but life is a theatre and sometimes we tend to overdo our characters, or put some make up on it...

Humans are social creatures, actually, our capacity to collaborate, to share, to create societies has determined that we're allegedly on top of the animal kingdom (though puking over it all the venom that will eventually poison us) but the kind of fake sociability that has developed in the last years is an evolutionary penalty for most of the population, cause it benefits only a few. Putting up in facebook (or other platforms for exhibitionism) information about what you drink, smoke, vote... When you join as friend to someone that others would consider "uncomfortable", that ends up putting you in that same group of "uncomfortables" for them. That "them" could be an employer, someone you do business with, the government..., so, why the hell do it public to everyone?...