No client transport named ‘null’ found

2013-08-13

Tänkte bara skriva en rad om detta hemska exception… När man googlar om det här felet så hittar man inlägg efter inlägg efter inlägg med folk som råkat ut för det här, men ingenstans finns det några vettiga svar.

När uppstår det här felet?

Jo, framförallt när man jobbar med Webservices. Detta fel uppstår som ett RemoteException, och av alla google-svar att döma så verkar det vanligaste felet till denna exception vara att endpoint inte är satt korrekt/saknas. Därför torde steg ett i felsökningen vara att kolla att du har en endpoint, och att den är giltig. Du kan kolla detta genom att öppna din browser, skriv in endpoint-adressen och tryck enter. Får du inget svar? Då vet du vad du skall kolla på härnäst. Då är din endpoint fel.

Om du dock får svar, och allt ser ut att vara frid o fröjd, men när du deployar ditt projekt på servern så fungerar det ändå inte.

Då har du troligtvis råkat ut för samma sak som mig: BRANDVÄGG! Kolla att brandväggen låter servern kommunicera utåt med internet (eller framförallt din endpoint-adress).

Så detta får bli en liten minnesanteckning för framtiden… Kolla även brandväggen!

Annonser

Refactoring är inte alltid så lätt…

2013-07-29

Jag har stött på ett litet problem; Jag sitter och skall göra en liten refactoring av en klass och funderar på hur man bäst skall gå tillväga. Här är min main-kod i min klass:


try {
 initialize();
 if (this.orderId.equals("")) {
  createErrorResponseOrderNumberIsMissing();
  outputResponse.println(jsonReturn.toJSON());
  return;
 }
 this.orderDocument = allOrders.getDocumentByKey(this.orderId);
 if (this.orderDocument == null) {
  createErrorResponseOrderNotFound();
 } else {
  processOrderDocument();
  createResponseMessage();
 }
 outputResponse.println(jsonReturn.toJSON());
} catch(Exception e) {
.... exception handling snipped out of this example... not of interest right now! ...
}

Mitt problem med koden är att jag inte gillar att ha två olika exit-points i koden; du har en om ordernummer saknas och en annan för alla andra resultat. Jag skulle vilja ha endast en exitpoint – den som finns precis före catch-satsen. Men hur löser jag att det finns två villkor som måste uppfyllas varav det andra inte kan kontrolleras såvida inte en lookup utförs, där argumentet för lookupen baseras på det första värdet i villkoret?

Jag vill ju inte utföra lookupen om ordernummer inte finns angiven – då kommer jag att få en massa följdfel som inte är önskvärt. Jag skulle önska att lookupen hellre returnerade en exception om man anger ett sträng utan innehåll som argument. Det gör den. Det blir då NullPointerException. Jag skulle kunna fånga upp detta fel och hantera detta, men eftersom det kan bli NullPointerException var somhelst i koden så har jag ingen koll att just denna NPE handlar om att ordernummer saknas.

Hur löste jag detta?

Det var tanken på att hantera ett exception som ledde mig åt rätt håll. Eftersom lookupen utförs av en 3:e parts produkt som jag inte kan modifiera så beslöt jag mig för att ändra min klass ”ReturnMessage” – vilket är den lokala variabeln jsonReturn som sätts i initialize() till objektet ReturnMessage;

this.jsonReturn = new ReturnMessage();

Jag beslutade mig för att den inte fick initieras utan argument. Konstruktorn utan argument togs bort så att man måste ange ReturnMessage(String id) istället. I konstruktorn kan jag sedan slänga en egen (ny) exception; OrderIdMissingException.

Nästa förändring som var tvunget för att detta skulle fungera är att ändra hur man initierar jsonReturn. Detta lades till i initialize()-metoden:

this.jsonReturn = new ReturnMessage(getOrderId());

(Och nej – jag kan inte lägga in exception-kontrollen i ”getOrderId”-metoden, för denna används på fler ställen där det skall vara fullt legalt att använda en tom sträng och inget exception får då genereras!)

I main-funktionen kunde jag sedan lägga till catch-sats för detta exception och skapa felmeddelandet där istället:


catch(OrderIdMissingException exception) {
 createErrorResponseOrderNumberIsMissing();
}

Jag flyttade också outputResponse.println(jsonReturn.toJSON()); till finally-satsen. Så här blev koden till slut:


try {
 initialize();
  this.docOrder = allOrders.getDocumentByKey(jsonReturn.orderId);
  if (this.docOrder == null) {
   createErrorResponseOrderNotFound();
  } else {
   processOrderDocument();
   createResponseMessage();
  }
 } catch(OrderIdNotSuppliedException missingOrderIdException) {
  createErrorResponseOrderNumberIsMissing();
 } catch(Exception e) {
... exclueded exceptionhandling from example...
 } finally {
  outputResponse.println(jsonReturn.toJSON());
 }

Eller är det någon som har förslag på en bättre lösning?


jQuery replaceClass

2013-05-28

Det finns en funktion jag saknar i jQuery core och det är replaceClass. Jag vill byta ut en klass mot en annan, och skulle vilja slippa att göra följande:
$(object).removeClass("x").addClass("y");
För att öka läsbarheten i min kod så skulle det vara enklare att läsa följande:
$(object).replaceClass("x", "y");
Nu verkar det finnas en slags koncencus att replaceClass inte skall införas i core, då allt för få ser någon anledning till att införa detta. Synd tycker jag.

Men jag har själv skrivit följande och använder i mina projekt där jag behöver. Det är ju enkelt att infoga kod i jQuery:


 jQuery.fn.extend({
  replaceClass: function( replaceFrom, replaceTo ) {
   return this.each( function() {
    var $this = $(this);
    if ($this.hasClass(replaceFrom)) {
     $this.removeClass( replaceFrom ).addClass( replaceTo );
    }
   });
  }
 });

Då blir det en enkel sak att byta ut en klass. Exempel:


<html>
....

<ul><li class="x">asdfasdf</li>
<ul><li class="x">asdfasdf2</li>
</ul>
<script>

function performReplace() {
 $("ul li").replaceClass("x","y");
}
(function() { $("button").click( performReplace ); })();
</script>
...

Jag tycker att läsbarheten i funktionen performReplace blir avsevärt mycket bättre – inga if-satser, inga krångligheter. Du gör en vanlig jQuery selektering och utför en replaceClass på resultatet. Precis på samma sätt som addClass, eller vilken annan jQuery funktion som helst.
Det som kan diskuteras är ju argumenten – hur vet jag vilken som är vilket? Det torde vara standard från alla andra skript-språk: Det första argumentet är alltid de facto vilken funktionen skall agera på och det andra argumentet vad som skall utföras när det första resulterar i ‘true’, dvs det första argumentet är VAD som skall ersättas och det andra vad det skall ersättas MED.

Solklart?


Alla kan vi göra nybörjarmisstag…

2013-03-19

Jag tycker att jag själv är en rätt så duktig programmerare och sköter mitt jobb och tar fram den ena kodsnutten efter den andra och får allt att fungera, men jag måste erkänna; även jag gör nybörjarmisstag ibland!

Tänkte faktiskt dela med mig av ett här. Det tog mig någon timma innan jag gav mig själv en ”facepalm” och korrigerade felet på en sekund. Allt handlar om ”typecasting”, dvs när man konverterar ett objekt till ett annat objekt t.ex. (som i det här fallet) en double till int.

Bakgrund: Eftersom det i HTML finns en begränsning att ett input-fält inte kan ha mer än 32767 tecken så behövde jag i min kod räkna ut när jag överskrider ett fördefinierat tröskelvärde och därefter vidta åtgärder.

Så jag började med följande:


//Declared as constant in the top of the class!
private final int MAXIMUM_STRING_LENGTH = 32767;

public int getPercentOfFieldsize() {
int pct = 0;
try {
double testvalue = 16383;
pct = (int) Math.round( (testvalue / MAXIMUM_STRING_LENGTH)*100f);
System.out.println("Current pct: " + pct);
} catch (Exception e) {}
return pct;
}

Ok, så här långt är allt frid och fröjd. Jag fick ut att pct i det här fallet blev 50 och då visste jag att procentuträkningen var korrekt. Trodde jag. Jag ersatte därefter variablen testvalue med min genererade sträng:


String full = stringGenerator.toString();
int pct = (int) Math.round( (full.length() / MAXIMUM_STRING_LENGTH) * 100f);

Plötsligt blev resultatet 0! Detta trots att det borde ha varit runt 50 såsom mitt testvärde var. Ser Ni vad felet är?

Metoden .length() returnerar en int.

Konstanten MAXIMUM_STRING_LENGTH är en int.

Om du dividerar en int med en annan int så kommer resultatet att konverteras till en int innan det sker en multiplikation med 100f. Dela 16000 med 32767 och avrunda detta till en int och du får 0!

Lösningen var att konvertera konstanten till en double:


private final double MAXIMUM_STRING_LENGTH = 32767;

Då kommer nämligen att både täljare och nämnare att behandlas som double och divisionen returnera en double! *duh* Ett sådant billigt nybörjarmisstag…


SOLID programmering; del 2

2013-03-18

Dags för del 2 i serien om SOLID.

Del 2 – Open/Closed Principle

Bokstaven ”O” i akronymen SOLID betyder ”Open/Closed Principle”. Den dikterar följande:
En klass skall vara öppen för tillägg men stängd för ändringar.

Så vad betyder det egentligen? Jo, eftersom man i en produktionsmiljö vill ändra källkoden så lite så sällan som möjligt så bör man designa sitt program till att tillåta att programmet kan ändra sitt beteende utan att man behöver ändra källkoden. Att ändra källkoden innebär kodgranskning, godkännande osv osv, som kan vara en ganska omfattande procedur.

Det finns flera olika tolkningar om hur detta skall uppnås. En av de tidigaste sätten dikterade att du skall aldrig ändra en klass såvida den inte innehåller buggar och rena fel. Tillägg och ändringar skall läggas i en ny klass som ärver från den ursprungliga klassen. Den nya klassen behöver inte alltid ens ha samma interface som den klassen som den ärver ifrån.

Under 90-talet utvecklades dock en annan variant av arv; arv via abstrakta interface. Detta innebär att man ärver från en abstrakt basklass och med polymorfism kan den nya klassen utföra den nya funktionen baserat på ärvda eller nya interface.

I den här delen så har jag inte något kodexempel som illustrerar detta, då det mer handlar om arkitektur och design. Om jag hittar ett bra exempel så kommer jag att återkomma till denna princip.


Sortering av en Collection med Vector

2013-03-11

Här kommer ett litet intressant programmeringsproblem jag råkade ut för nyligen.

Att sortera en Vector är inga större problem; du anropar bara Collections.sort(myVector) och den sorterar alla items i din Vector. Men hur gör man egentligen om man har en hel collection av vectorer där man sedan skall sortera vectorerna baserad på ett av deras index/items?

T.ex. jag har


Vector vector1 = new Vector();
Vector vector2 = new Vector();
Vector vector3 = new Vector();

där jag har populerat ett antal items i varje vector, t.ex:


vector1.add("e");
vector1.add("f");
vector1.add("g");

vector2.add("a");
vector2.add("x");
vector2.add("m");

vector3.add("s");
vector3.add("o");
vector3.add("p");

och jag sedan lägger dem alla i en ny vector:


Vector<Vector> all = new Vector<Vector>();
all.add(vector1);
all.add(vector2);
all.add(vector3);

Om jag nu försöker skriva Collections.sort(all) så kommer det inte att fungera; editorn kommer att klaga på ”Bound mismatch: The generic method sort(List<T>) of type Collection is not…….” och du kommer inte att kunna kompilera koden. Hur gör jag om jag vill sortera på varje vectors första item? Eller andra? Eller låta användaren välja?

För att lösa detta så behöver vi skapa en s.k. Comparator, som implementerar metoden compare:


import java.util.Comparator;
import java.util.Vector;

public class VectorComparator implements Comparator<Vector<String>> {
@Override
public int compare(Vector<String> o1, Vector<String> o2) {
//TODO: Auto-generated code
}
}

Metoden compare skall returnera -1, 0 eller 1 beroende på om o1 är större än, lika med eller mindre än o2. Då behöver vi veta vilket index som vi skall använda oss av i vector o1 och o2. Vi lägger till följande privata fält och konstruktor för klassen:


private int useIndex = 0;

public VectorComparator() {
}
public VectorComparator(int index) {
this.useIndex = index;
}

Och då kan vi beräknade compare-metoden till följande:


return o1.get(useIndex).toString().compareTo( o2.get(useIndex).toString());

Här är hela klassen då jag har lagt till lite felhantering i compare-metoden:


import java.util.Comparator;
import java.util.Vector;

public class VectorComparator implements Comparator<Vector<String>> {
private int useIndex = 0;

public VectorComparator() {
}
public VectorComparator(int index) {
this.useIndex = index;
}

@Override
public int compare(Vector<String> o1, Vector<String> o2) {
if (useIndex <= o1.size() && useIndex >= 0) {
return o1.get(useIndex).toString().compareTo( o2.get(useIndex).toString());
} else {
throw new RuntimeException("Index out of bounds; max size is '" + Integer.toString(o1.size()) + "'!");
}
}
}

Nu kan vi använda vår comparator för att sortera:


VectorComparator comparator = new VectorComparator(1);
Collections.sort(all,comparator);

och vår collection av vectorer kommer att vara sorterad på varje vectors andra item!

Svårare än så var det inte…

Vill du veta mer om Comparator? Läs här: Vogella.com eller på Java Doc.


SOLID programmering; Del 1

2012-10-22

SOLID är en akronym för 5 principer inom programmering som om de används korrekt hjälper dig att skapa stabil, utvecklingsbar och kvalitativt bra kod. SOLID introducerades av Michel Feathers och har uppmärksammats och lyfts fram av Robert C. Martin. SOLID skall ses mer som riktlinjer än som regler då det alltid kommer att finnas tillfällen då man inte kan tillämpa en eller flera av dessa principer, men om man alltid strävar efter att följa dem så kommer man i längden att underlätta livet för både dig själv och andra programmerare.

Jag tänkte ta upp dessa fem principer i en serie på 5 blogginlägg, och titta lite närmare på vad de står för. Jag börjar från början med bokstaven ”S” – ”Single Responsibility Principle”.

Del 1 – Single Responsibility Principle

Single Responsibility Principle deklarerar att varje klass skall ha endast ett ansvar och det ansvaret skall vara till fullo inkapslad i klassen. Alla de tjänster som klassen tillhandahåller skall vara för att tillgodose det ansvaret och ingenting annat.

Vad innebär detta? Vad är ”endast ett ansvar”? Såsom jag ser det så är definitionen av ”endast ett ansvar” beroende av vad klassen förväntas utföra. T.ex. en klass skall endast hämta en kund från kundregistret. Den skall inte både göra det OCH skriva ut kunduppgifterna på webben. Detta är två skilda ansvar. Det gör att om man behöver ändra i kundregistret så påverkas bara klassen som hämtar kunduppgifterna och ingenting i front-end påverkas. Och det är ju precis det vi vill – kunna ändra utan att påverka andra saker.

Robert C. Martin definierar detta ansvar till att vara att

en klass skall endast ha en anledning att förändras.

Han jämför med att en klass inte skall sammanställa/kompilera (compile) och skriva ut en rapport därför att den då har två anledningar till att förändras: Antingen kan rapporten (data) förändras eller så kan formatet för rapporten ändras. Detta gör att det blir svårt att ändra i klassen.

Jag skulle vilja ta denna princip ytterligare ett steg ner i klass-hierarkin: Även metoderna i en klass skall utgå från den här principen: De skall hantera/utföra endast en sak, alternativt ha endast ett ansvarsområde (enligt Robert C Martins definition). Så fort de har ansvar för flera saker så skall den delas upp i flera metoder. Detta gör att metoden då blir lättare att testa med Unit Tester och färre fel letar sig in i koden.

Ett sätt att hitta en klass eller metod som har för stort ansvarsområde är att om du har svårt att ge klassen/metoden ett meningsfullt namn som tydligt specificerar vad den gör – då har du troligtvis fel scope på din klass/metod och bör bryta upp den i två eller flera block. I mitt exempel så blir det tydligt: Jag kan döpa min klass till t.ex. ”CustomerLookup”; det är tydligt att då avses endast en läsning från kundregistret på en (1) kund. Inget annat. Om jag hade varit tvungen att döpa den till ”CustomerLookupAndPrint” så avslöjas att klassen gör för mycket. Ordet ”And” betyder ju att det är två saker som kombineras…

Glöm inte del 2 i Single Responsibility Principle!

Glöm nu inte bort att även de exponderade metoderna skall stödja ansvaret och ingenting annat! Det är väldigt lockande att ge en massa publika metoder bara för att underlätta saker och ting, men som i själva verket inte är klassens ansvar.

Ta t.ex. min klass ”CustomerLookup” som har som ansvar att hämta en kund från kundregistret. Det är väldigt lockande att expondera toString() och därigenom bestämma hur den skall formatteras på webben. Faktum är att detta är ju inte klassens ansvar! Således skall toString() inte bestämma över formattering. Däremot skall CustomerLookup expondera en metod för att ge t.ex. kundens namn ”getCustomerName()” (eller bara customerName()), och en annan metod för adressen osv. Då får klassen som sedan hanterar formattering på webben själv bestämma vilken uppgift som placeras vart och hur.

Som kuriosa; Vad skall då toString() vara i CustomerLookup? Personligen skulle jag använda toString() för att ge hela kund-recordsetet i en kommaseparerad sträng. Då är det lätt att använda den i en jämförelse för att se om kunduppgifterna har ändrats;

CustomerLookup customer = new CustomerLookup("777777-7777");
String compare = customer.toString();
String anotherCompare = "7777777-7777,Nisse Hult, Avägen 1, 999 99 Storstad";
if (compare.equalsIgnoreCase(anotherCompare)) {
//Nothing has changed...
} else {
//Oh.... Something is different here!
}

Ok, nu hamnade vi på ett litet sidospår här… men jag tror jag har gjort tydligt om vad Single Responsibility Principle innebär för mig.

Detta är för mig en av de viktigaste principerna i hela SOLID-akronymen. Det räcker väldigt långt att börja med denna princip. Följ mig i nästa avsnitt så skall jag gå igenom nästa bokstav: ”O” – ”Open/Closed principle”!

Läs mer…

SOLID SOLID (Object-oriented Design) enligt Wikipedia.
Single Responsibility Principle SRP – Single Responsibility Principle enligt Wikipedia.