2013-10-25 13 views
8

c'è un modo per abbreviare questa linea su Ruby?Ruby una riga se dichiarazione di reso

if (res = bla_permission_invalid).is_a? String then return res end 

su

def something # many things that like this 
    if (res = bla_permission_invalid).is_a? String then return res end 
    # do something else 
    return true 
end 

quando il contenuto di bla_permission_invalid sono qualcosa come stringa

def bla_permission_invalid 
    return invalid_address_report_func if invalid_address? 
    return permission_error_report_func if @user.not_one_of? [ :group1, :group2 ] 
    return nil 
end 

invalid_adress_report_func e permission_error_report_func ritorna

+4

Sembra che questo codice sta cercando di reinventare eccezioni ... –

risposta

4

Se p I valori ossible sono String e NilClass, quindi il codice può essere semplificata a questo:

def something 
    res = bla_permission_invalid() 
    return res if res # strings are truthy, so they'll be returned but nil will proceed 

    # do something else 
    true 
end 
+0

C'è un modo per sostituire 'return res if res' perché 'res' viene ripetuto qui? – hlcs

+0

@hlcs: dalla cima della mia testa - no. –

5
def something 
    bla_permission_invalid || (
    # do something else 
    true) 
end 
+0

non hai bisogno del 'return' qui. E trovo i blocchi di codice come questo difficile da leggere. Ma questo funzionerà. –

+0

ha aggiornato la risposta – tihom

2

Per divertimento, si potrebbe riscrivere il metodo something in questo modo:

def something 
    true.tap do 
    bla_permission_invalid.tap { |res| return res if res.is_a? String } 
    # do something else (thx Sergio) 
    end 
end 

Ma ancora più importante, Mark Thomas merita di credito per la sua osservazione, il problema in questione dovrebbe essere risolto utilizzando eccezioni personalizzate.

L'approccio al codice di errore è valido in lingue che non hanno eccezioni. Ruby li ha.

+0

Dov'è la parte "fai qualcos'altro"? :) –

+0

In che modo le eccezioni fanno parte di OOP? È un concetto totalmente indipendente ("codici di errore" e "eccezioni") –

+0

@SergioTulentsev: le cose si confondono già nella mia testa e non ho ancora aperto la bottiglia di Bowmore. Se separo la dichiarazione dicendo che: 1. "Il codice originale fa troppe domande, violando il principio 'tell, do not ask', che può essere soddisfatto da OOPing di più", e 2. "Mark Thomas è morto in la sua osservazione che questo è il caso di eccezioni ", è meglio? Immagino non molto. Come biologo, semplicemente non sono abbastanza professionale nella programmazione, sei il maggiore di CS là fuori, aiutami ad esprimere i miei sentimenti, per favore! –

1

Mark Thomas ha già notato in his comment che sembra che tu stia cercando di gestire gli errori da solo utilizzando una sorta di identificatore di stringa. Si potrebbe utilizzare le eccezioni invece:

class AddressError < StandardError; end 
class PermissionError < StandardError; end 

def something 
    bla_permission_invalid 
    # do something 
    true 
end 

def bla_permission_invalid 
    raise AddressError if invalid_address? 
    raise PermissionError if @user.not_one_of? [ :group1, :group2 ] 
end 

Nel codice precedente something chiama bla_permission_invalid, svolge il suo lavoro e restituisce true. Se viene sollevata un'eccezione in bla_permission_invalid, automaticamente si propaga sullo stack delle chiamate, non è necessario restituirlo esplicitamente da something.

per gestire l'eccezione:

begin 
    something 
rescue AddressError 
    # handle address error 
rescue PermissionError 
    # handle permission error 
end 
+0

E lasciatemi solo commentare, che 'raise' ha un popolare alias' fail', quindi invece di 'raise AddressError if invalid_address?', Possiamo 'fail AddressError if invalid_address?'. –