Consegui solucionar, ao capturar o (Exception) não houve nenhum erro na compilação, todavia, vou fazer algumas alterações na classe logar para evitar futuros erros. Obrigado pessoal.

Ah, tá não deu erro na compilação, então está certo, né?

@Mateus, realmente faça isso, altere sua classe. A resposta te alerta muito bem nos perigos que você corre. Se a resposta te ajudou, seria interessante marcá-la como aceita. Olhe esse link

Sim bigown, está tudo certo agora, obrigado pelas dicas, são muito úteis.

+1 pelo comentário sobre nao dar erro na compilação @bigown

Eu quero melhorar a resposta mas como é possível 3 pessoas acharem que tem algo errado e nenhuma dizer o que é? Quem me conhece sabe que eu odeio postar algo ruim que vai prejudicar outras pessoas. Faça um favor a todos e mostre onde está o problema.

Eu não negativei mas senti necessidade de colocar uma resposta porque a sua não explica o porquê do aviso/erro. Ela limita-se a criticar(mesmo que seja de forma construtiva) o código do AP. Não sei se será essa a razão dos negativos. No meu caso foi suficiente para não votar nela.

@ramaral ok, posso concordar com isso, eu entendo isto, só não entendo o negativo. Eu acho que a sua foi a além do que deveria, eliminou uma coisa que pode ser fundamental para ele (eu disse pode, nem eu, nem você podemos saber disto sem ver o resto), eu mesmo falei sobre o retorno do booleano, mas não cravei que não é para usar. Vou negativar a sua por causa disto? Claro que não. Mas eu sei esses negativos não estão aí por erro. No chat conversamos sobre isto. Eu tenho recebido uma quantidade enorme de negativos porque as pessoas não gostam de mim. Só posso acreditar nisso,senão teria comment

Julgo que ambos sabemos que retornar false não é a melhor forma de reportar um erro. Quem chama o método tem de fazer um teste mesmo que não seja a melhor altura para tratar o erro e teste por teste seria melhor então fazer aí o try/catch recebendo toda a informação sobre o que tinha sucedido. Em relação aos negativos sem comentário é algo mau com que temos de viver.

@ramaral eu não sei disso não :P, nunca leu este meu par de P/R? pt.stackoverflow.com/q/21767/101 Eu entendo que nem todos concordam com isto, mas fundamentei bem o que digo lá. Eu não sei se faria neste caso específico, mas não vejo nada errado em fazer isto, dependendo do contexto completo. De alguma forma vai ter que pegar esta informação, se deve ser um return, se vai setar uma propriedade ou vai usar um método que vai descobrir isso por conta própria, eu só saberei vendo a classe ou a aplicação toda. Eu estou quase implorando para saber o que tem de errado na resp. pra melhorar

Sim eu sei que o assunto possa ser discutível. O que aqui está em causa não é escolher entre retornar false ou lançar uma excepção mas se já é altura de tratar a excepção. Fazer um catch e retornar false não é tratar a excepção é apenas mascará-la(com todos os possíveis problemas que isso pode acarretar). Na minha opinião, quando não se consegue tratar a excepção o melhor é deixá-la propagar.

Discordo que estaria mascarando ela (claro que não poderia ser Exception). Eu acho que realmente não precisa dela. Mas o que eu entendi é que ele está usando isto para saber se está logado ou não*. Isto não é mascarar. Acho que você leu boa parte que escrevi sobre o assunto e sabe que concordo com o que está dizendo, só acho que este caso está tratando a exceção de forma semântica. Poso estar enganado. E acho que teria forma melhor de fazer isto, só não quis mexer nessa parte.

Ao ver a documentação da OleDbDataReader verifiquei que é necessário(esqueci) fazer o close do reader. Se a intenção do método é verificar se existe um usuário {Pnome, Psenha} então justifica-se o retorno mas não deveria ser utilizada o try/catch, bastava verificar o retorno de reader.Read(). Então também o nome do método está mal. São tantas as coisas que agora julgo que o melhor era ter ficado pelos 3 primeiros parágrafos da minha resposta e não ter sugerido qualquer alteração ao código.

Sim, concordo plenamente. Eu vou pensar em alguma coisa pra melhorar também.

Pronto, dei uma melhorada. Se alguém negativou por um motivo sério agora tem a chance de tirar o negativo ou me falar qual o problema persiste.

Queria apenas confirmar se entendeu que a nossa divergência se devia ao facto que estávamos a interpretar de forma diferente a razão do try/catch. Eu interpretei(mal) como tratamento de um eventual erro em reader.Read(); enquanto você interpretou(bem) como o tratamento de um erro em reader[1], o que indicaria que o usuário não está registado.

@ramaral sim, eu entendi isso. Faz parte. Não sei quem tá certo :P

O AP não respondeu, mas julgo que você tem razão: o que ele pretendia era verificar se o usuário está ou não registado.