보안 제한으로 인해 서비스가 null을 반환하거나 예외를 throw해야합니까? [닫은]

이 문제에 대해 더 숙련 된 개발자와 약간 의견이 다르며 다른 사람들이 이에 대해 어떻게 생각하는지 궁금합니다. 우리의 환경은 Java, EJB 3, 서비스 등입니다.

내가 작성한 코드는 물건을 얻고 물건을 만드는 서비스를 호출합니다. 내가 겪었던 문제는 의미가없는 null 포인터 예외가 있다는 것입니다. 예를 들어, 서비스에 객체 생성을 요청하면 null이 반환됩니다. 알려진 유효한 ID를 가진 객체를 찾으려고하면 null이 반환됩니다. 나는 내 코드에서 무엇이 잘못되었는지 알아 내려고 노력했다. 경험이 적기 때문에 일반적으로 내가 잘못한 것으로 가정하지만 null 반환의 이유는 보안이었습니다. 내 서비스를 사용하는 사용자 주체가 대상 서비스에 대한 올바른 권한을 가지고 있지 않은 경우 단순히 null을 반환합니다. 여기에있는 대부분의 다른 서비스는 잘 문서화되어 있지 않으므로 분명히 알아야 할 것입니다.

이는 서비스와 상호 작용하는 코드를 작성하는 개발자로서 혼동됩니다. 서비스가 사용자에게이 작업을로드하거나 해당 작업을 생성 할 수있는 적절한 권한이 없다는 것을 알려주는 예외가 있다면 훨씬 더 이해가 될 것입니다. 그런 다음 서비스가 예상대로 작동하지 않는 이유를 즉시 알 수있었습니다.

서비스를 작성한 숙련 된 개발자는 데이터를 요청하는 것은 오류 조건이 아니며 사용자가 데이터에 액세스 할 수없는 경우가 아니라 오류 조건에서만 예외를 처리해야한다고 주장했습니다. 이 데이터는 종종 GUI에서 조회되며 올바른 권한이없는 사용자의 경우 이러한 것들은 단순히 "존재하지 않습니다". 요컨대, 묻는 것은 잘못이 아니므로 예외는 아닙니다. 해당 사용자에게 "존재하지 않는"항목이 있으므로 Get 메소드는 널을 리턴합니다. 사용자가 해당 항목을 만들 수 없으면 Create 메서드는 null을 반환합니다.

이것이 정상적이거나 좋은 습관입니까? 나는 무슨 일이 일어나고 있는지 훨씬 쉽게 알기 때문에 예외를 사용하는 것을 선호합니다. 따라서 예를 들어 null을 반환하지 않고 잘못된 ID를 가진 객체를 요청한 경우 NotFoundException을 throw하는 것이 좋습니다.

예외는 오류가 있고 사물을 요청하는 것이 오류가 아닌 경우에만 발생합니다.

요청하는 것은 오류가 아닐 수 있지만 요청한 것에 대한 권한이없는 것은 일종의 오류입니다. 예외는 예외 조건을보고하는 특별한 방법으로, 특수 반환 값 대신 사용됩니다 (예 : null작성한대로 상황이 잘못 될 수있는 1 가지 이상의 이유가있을 경우 전혀 도움이되지 않음) 정확히 1 가지 가능한 이유, 다음 버전에서는 2 가지 이유가있을 수 있습니다. 따라서 null실패를 나타내는 반환 값으로 사용 하면 문제가 발생합니다.) 서비스가 원하는 방식으로 서비스를 제공하지 않는 이유를보고하지 않으면 설계가 잘못되었습니다.

특수 반환 값을 사용할지 여부 (예 : 음의 정수는 일반적으로 음이 아닌 정수를 반환하는 함수에 유용합니다), 예외, 전역 오류 처리기 또는 로거 등은 결국 구현 세부 사항입니다. 선택은 언어, 상황, 컨벤션에 따라 다르며 맛의 문제이기도합니다. 주요 포인트는이 있어야한다는 것입니다 몇 가지 알아내는 직접적인 방법 왜 뭔가가 작동하지 않습니다. 그렇지 않으면 유일한 옵션은 다른 옵션으로 쓰레기를 버리는 것입니다. 블랙 박스의 동작과 어떤 관련이 있는지 알아내는 것은 시간 낭비입니다.

String.substring()IndexOutOfBoundsException인덱스가 범위를 벗어나 면를 던집니다 . 나는 복귀에 어떤 이점이 생각할 수 없다 null철학적 - -에도 불구하고, 대신 하나가이 주장 할 수 String는 경계 밖에 아무것도 포함하지 않는, 그래서 null다음 논리적 반환 값을 것입니다. 논리적 철학적이며 실용적이라는 것은 분명히 두 가지 다른 동물입니다.

그것은 계약이 무엇인지에 달려 있습니다. 계약서에 존재하지 않는 것을 요청할 수 있다고 말하면 어떤 일이 발생하는지 (널 또는 널 오브젝트) 말해야합니다.

반면, 계약서에 먼저 다른 메소드 DoesSomethingExist()를 호출 ( ) 한 다음 Get메소드 를 호출해야 한다고 명시되어 있으면 계약은 존재하는 것만 가져올 수 있고 그렇지 않은 경우 예외를 던질 수 있다고 말할 수 있습니다. 예외 메시지 DoesSomethingExist()는 유용한 오류 메시지 인 "먼저 호출해야합니다"와 같은 메시지를 표시 할 수 있습니다.

질문에 대한 하나의 크기에 맞는 답은 없습니다. 예외 사용 여부 또는 null 반환 여부는 상황에 따라 다릅니다.

이것을 교의적인 관점에서 순수하게 보지 말고 사용자 인터페이스로 인터페이스를보십시오 . 사용자 인터페이스를 사용할 수 있어야합니다 . 따라서 무언가를하는 "올바른"방법에 대한 자신의 의견에 상관없이 인터페이스를 사용하는 사람의 관점에서 가장 유용한 방법을 선택하십시오.

호출자가 오브젝트가 리턴되지 않는 이유를 알아야하는 경우 예외가 적절합니다. 그러나 일반적인 개념이 "권한이 없으면 존재하지 않는 경우"인 경우 널이 허용됩니다.

특히 귀하의 경우 발신자가 서버에 로그인하거나 서버에 연결 해야하는 경우 항목을 조회하는 데 null이 완벽하게 허용됩니다. 그때 당신은 당신이 허락을받지 않았다는 말을들을 것입니다. 게이트를 지나면 볼 수있는 권한이없는 (또는 존재한다는 것을 알 수없는) 무언가를 검색 할 때 null을 얻는 것이 합리적입니다.

반면에 초기 연결 또는 로그인 단계가없는 경우 예외가 적합합니다. 호출자가 항목이 존재한다는 것을 알고 다시 가져 오지 못하면 API는 null을 반환하는 데 도움이되지 않습니다.

그러나 아이템을 만들려면 다른 이야기입니다. 아마도 권한, 잘못된 매개 변수, 서버 메모리 부족 등이 실패하는 데에는 많은 이유가있을 수 있습니다. 개발자에게 이러한 모든 조건에 대해 null이 부여되면 적절한 조치를 결정할 방법이 없습니다. .

따라서 질문에 대답하려면 서비스를 사용하는 사람의 관점에서 가장 유용한 솔루션이 무엇인지 자문하십시오. 당신 이 그것을 사용 하는 방식 이 비정형 적 일 수 있으며 가장 일반적인 경우 null이 정답입니다.

따라서이 문제에 대한 종교적 전쟁에 참여하지 말고이 특정한 문제에 적합한 것을 결정하십시오.

나는 그것이 나쁜 디자인 이라고 생각합니다 . 널 포인터는 올바른 대답이 아니며 관리하기 까다로울 수 있습니다.

사용자가 적절한 자격 증명없이 서비스를 연결하려고하면 명확하고 간결한 답변으로 답변해야합니다. 대답은 예외 또는 특수 객체 일 수 있지만 null은 아닙니다.

네트워크 링크가 끊어 지거나 기타 예상치 못한 심각한 오작동이 발생하면 널 응답을 남겨 두어야합니다.

또한 왜 null을 얻었는지 이해하는 데 시간이 걸립니다. 모든 코드는 이해하기 쉽고 사용하기 쉬워야합니다. 널값을 갖는 것은 아닙니다.

좋은 소프트웨어 디자인을 염두에두고 프로젝트 수명을 생각해야합니다. 말한
대로을 반환 null하면 고객에게 정보를 제공하지 않습니다. 당신에게 무슨 일이 있었는지 처음에 문제가 어디에 있는지 몰랐습니다. 또한 문서가 제공되지 않으면 엉망입니다.

예외를 던져서 무엇이 잘못되었는지 알 수 있습니다. 원하는 경우 표시된 텍스트를보다 구체적으로 사용자 지정할 수도 있습니다.

반면에 돌아 null오면 클라이언트가 무슨 일이 일어나고 있는지 조사하게됩니다.

또한, 다른 곳에있어 문제가 있음을 깨달았습니다 NullPointerException. 이제 그 함수의 반환을 저장하지 않는다고 상상해보십시오 ... if else블록 으로 해당 함수에 대한 각 호출을 둘러싸 야합니다 ...

내 관점에서 돌아 오는 null것은 나쁜 습관이다.

서비스를 작성한 숙련 된 개발자는 데이터를 요청하는 것은 오류 조건이 아니며 사용자가 데이터에 액세스 할 수없는 경우가 아니라 오류 조건에서만 예외를 처리해야한다고 주장했습니다.

제 관점에서 이것은 말이되지 않습니다.

권한 이 없는 데이터를 쿼리 하면 적절한 액세스 권한이 없으면 예기치 않은 결과 가 발생하여 결과를 얻지 못 하므로 예외가 발생 합니다.

유추 : GET권한이없는 응답 코드 는 200 ok데이터 가 없으며 실제로 401 Unauthorized입니다.

null을 반환하는 것은 좋지 않습니다. 아무 것도 말해주지 않습니다. 예를 들어, 앱이 무언가를 찾으려고 시도하고 보안 문제 모두에 대해 응답이 null이고 항목이 존재하지 않으면 두 가지의 차이점을 어떻게 알 수 있습니까?

응용 프로그램이 의미있는 응답을 통해 다음에 수행 할 작업 또는 문제 해결 방법에 대한 논리적 선택을 할 수 있습니다.

근본 원인이 인증되지 않은 사용자 인 경우 pretty-message-page (및 관심있는 사람에게 알림)로 리디렉션되는 하드 HTTP 401 응답을 선호합니다. 승인 관련 원인은 사례별로 다릅니다. HTTP 응답 (403)을 반환하는 인수와 서비스 응답에 올바른 형식의 코드 / 메시지를 반환하는 인수가 있습니다.

예외는 예외적 인 상황에서만 사용해야하며 문제가 발생했음을 의미합니다. "허용되지 않음"을 의미하기 위해 오버로드되어야한다는 데 동의합니다. (널 리턴 값도 마찬가지입니다. "허용되지 않음"을 의미하는 데 동의하지 않습니다.)

악마를 옹호하기 위해 널 돌려주는 편을 시도 할 것이다.

제 생각에는 이런 종류의 대응이 거의 수용 가능한 상황이며,이 경우와 같이 보안이 관련된 경우가 있습니다.

권한이없는 사람이 알 수없는 시스템 세부 정보를 실수로 제공하는 것은 매우 쉽습니다. 이것은 피해야합니다.

예를 들어, 사용자 이름 및 비밀번호 검사기를 사용하십시오. 별도의 오류 코드로 "사용자 이름을 찾을 수 없음"오류와 "잘못된 암호"오류를 반환하면 누군가 먼저 유효한 사용자 이름을 찾은 다음 암호를 찾을 수 있으므로 심각한 보안 문제가 발생할 수 있습니다. 일반적인 "잘못된 사용자 이름 / 암호"를 반환하는 것이 더 좋습니다.

따라서이 특별한 경우에 나는 돌아 오는 것이 거의 괜찮다고 말하고 싶지만 null, 함께 일하는 것은 매우 불쾌 할 것입니다.

클라이언트 가이 메소드를 호출하고 null을 반환 할 때 return null이 비우호적이라고 생각합니다. 클라이언트는 발생한 상황과 왜 null을 반환했는지 알지 못합니다. 따라서 우리는 의미가있는 execption을 던져야하고이 execption을 설명하는 문서를 제공해야합니다.