A função assert do Solidity destina-se a verificar apenas instruções avaliadas como true. Ter uma instrução false passada para essa função indica que o código não está funcionando corretamente ou que a função está sendo mal utilizada, por exemplo, para validar a entrada.

Exemplo 1: O código a seguir usa a função assert para verificar uma instrução falsa.

contract A {
    B b = new B(7);

    function checkWithAssert(){
        assert(b.retValue() == 21);
        ...
    }

}

contract B {
    uint _par;
    constructor(uint par){
        _par = par;
    }

    function retValue() returns(uint){
        return _par;
    }
}

Essa expressão sempre será nula, pois faz referência a um ponteiro de função, e não ao valor de retorno da função.

Exemplo 1: A seguir condição nunca será disparada. O predicado getChunk == NULL sempre será "false", pois getChunk é o nome de uma função definida no programa.

  if (getChunk == NULL)
    return ERR;

Como variáveis locais são alocadas na pilha, quando um programa retorna um ponteiro para uma variável local, ele está retornando um endereço de pilha. Uma chamada de função subsequente provavelmente reutilizará esse mesmo endereço de pilha, substituindo assim o valor do ponteiro, que já não corresponde à mesma variável uma vez que a estrutura de pilha de uma função é invalidada quando esta é retornada. Na melhor das hipóteses, isso fará com que o valor do ponteiro mude inesperadamente. Em muitos casos, isso faz com que o programa trave da próxima vez em que ocorrer a desreferência ao ponteiro. O problema pode ser difícil de depurar, pois a sua causa está muitas vezes bem distante do sintoma.

Exemplo 1: A função a seguir retorna um endereço de pilha.

char* getName() {
  char name[STR_MAX];
  fillInName(name);
  return name;
}

Métodos estáticos não podem ser substituídos por definição, uma vez que pertencem à classe e não a uma instância da classe. Mesmo assim, existem casos em que parece que um método estático foi substituído em uma subclasse, o que pode causar confusão e fazer com que uma versão incorreta do método seja chamada.

Exemplo 1: O exemplo a seguir tenta definir uma API para a autenticação de usuários.

class AccessLevel{
  public static final int ROOT = 0;
  //...
  public static final int NONE = 9;
}
//...
class User {
  private static int access;
  public User(){
    access = AccessLevel.ROOT;
  }
  public static int getAccessLevel(){
    return access;
  }
  //...
}
class RegularUser extends User {
  private static int access;
  public RegularUser(){
    access = AccessLevel.NONE;
  }
  public static int getAccessLevel(){
    return access;
  }
  public static void escalatePrivilege(){
    access = AccessLevel.ROOT;
  }
  //...
}
//...
class SecureArea {
  //...
  public static void doRestrictedOperation(User user){
    if (user instanceof RegularUser){
      if (user.getAccessLevel() == AccessLevel.ROOT){
        System.out.println("doing a privileged operation");
      }else{
        throw new RuntimeException();
      }
    }
  }
}

À primeira vista, esse código parece bom. No entanto, como estamos chamando o método getAccessLevel() em relação à instância user, e não contra as classes User ou RegularUser, isso significa que essa condição sempre retornará true e a operação restrita será realizada mesmo que instanceof tenha sido usado para entrar nessa parte do bloco if/else.

A Especificação de Serialização de Objeto Java permite que os desenvolvedores definam manualmente campos Serializáveis para uma classe especificando-os na matriz serialPersistentFields. Esse recurso somente funcionará se serialPersistentFields for declarado como private, static e final.

Exemplo 1: A seguinte declaração de serialPersistentFields não será usado para definir campos Serializable, pois não é private, static e final.

class List implements Serializable {
public ObjectStreamField[] serialPersistentFields = { new ObjectStreamField("myField", List.class) };
...
}

Chamar Object.equals() contra um array é um erro na maioria dos casos, pois isso verificará a igualdade dos endereços dos arrays, em vez da igualdade dos elementos dos arrays, e, em geral, deve ser substituído por java.util.Arrays.equals().

Exemplo 1: O exemplo a seguir tenta verificar dois arrays utilizando a função Object.equals().

...
  int[] arr1 = new int[10];
  int[] arr2 = new int[10];
  ...
  if (arr1.equals(arr2)){
    //treat arrays as if identical elements
  }
...

Isso quase sempre resultará em um código que nunca é executado, a menos que, em algum momento, houver uma atribuição de um array ao outro.

Certas famílias de funções são implementadas como funções em algumas plataformas e como macros em outras. Se as funções dependerem de um recurso compartilhado que é mantido internamente em vez de ser transmitido quando elas são invocadas, essas funções deverão ser usadas no mesmo escopo de programa, caso contrário, o recurso compartilhado será inacessível.

Exemplo 1: O código a seguir usa pthread_cleanup_push() a fim de enviar a função routine para a pilha de limpeza do thread de chamada e, em seguida, é retornado. Como pthread_cleanup_push() e sua função parceira pthread_cleanup_pop() são implementadas como macros em plataformas diferentes do IBM AIX, a estrutura de dados criada por pthread_cleanup_push() não será acessível a chamadas subsequentes para pthread_cleanup_pop(). O código não conseguirá compilar ou apresentará um comportamento incorreto em tempo de execução em todas as plataformas nas quais essas funções são implementadas como macros.

void helper() {
   ...
   pthread_cleanup_push (routine, arg);
}