문제

직장에서 string.isnullorempty가 세션 변수로 잘못 사용한 사건 후, 내 동료 동료는 이제 string.isnullorempty의 사용을 수락하지 않습니다. 일부 연구 후, 분명히 MSDN의 IsNullorEmpty에 대한 버그가 있습니다 (링크) (맨 아래에서 노트를 읽습니다) :

2006 년 4 월 4 일 현재, 최적화가 켜져있을 때이 메소드가 실패하게하는 버그 (JIT에서 가능)가 있습니다. C#과 VB 모두에 영향을 미치는 것으로 알려져 있습니다.

자세한 정보는 여기에서 찾을 수 있습니다 (링크). Microsoft 버그는 '아마도'고정 된 포스트 오카이지만 불행히도 내 고용주는 여전히 vs2005를 사용합니다. 그러나 2008 년에 문제가 해결되면 그렇게하십시오. 나에게 괜찮습니다.

내 동료가 isnullorempty와 함께 내 코드를 거부하는 것은 맹인 무지 (IMO)입니다. ~ 아니다 세션 변수에 대한 오용 이외의 다른 사용. 나는 우리 코드 전체에 IsNullorEmpty를 사용하여 아무런 문제없이 사용했습니다. 개인적으로, 나는 한 진술에서 두 가지 일을하는 것보다 훨씬 더 읽기 쉬운 것을 발견했습니다.

주제에 대한 의견에 대해 인터넷 검색을 한 후, 나는 프로/사기꾼을 취하는 사이트를 발견했습니다. 다음은 이것에 대해 읽은 사이트 중 일부입니다.

https://blog.rthand.com/post/2006/06/22/1063.aspx

http://www.omegacoder.com/?p=105

하나의 사이트 (http://dotnetperls.com/isnullorempty) 방법 (IMHO)을 꽤 잘 요약합니다.

여기서 우리는 문자열 유형에서 isnullorempty 메소드를 보았습니다.이 방법은 문자열이 저장 또는 사용에 적합한 지 여부를 확인하는 상대적으로 비교적 효율적인 방법을 제공합니다. 그러나 성능의 경우 수동 널 검사를 사용하는 것이 좋습니다. 빈 줄은 다른 방식으로 테스트 할 수 있으며 여기에서 내 연구에 따르면 검사 길이가 가장 빠릅니다.

VS2008/2010 등에 버그 수정이 제자리에 있고 올바르게 작동한다고 가정하면 어떤 이유가 있습니까? ~ 아니다 vs2005 이상으로 string.isnullorempty를 사용하려면? 나는 이것이 어리석은 작은 방법에 대해 약간 과잉으로 보일 수 있다는 것을 알고 있지만, 무대 뒤에 더 많은 것이 있는지, 누군가가 다른 설명이 있는지 알고 싶습니다.

도움이 되었습니까?

해결책

이 문제는 .NET 2.0 SP1에서 수정되었습니다. 지금 사용을 피할 이유가 없습니다.

.NET 2를 사용하는 경우 어쨌든 다른 많은 이유로 SP1이 있어야합니다. 더 이상 존재하지 않는 버그에 대해서는 피해야 할 이유가 없습니다.

다른 팁

나는 그 버그에 대해 들었고, 수집 할 수있는 것에서 실제 코드에서는 결코 일어나지 않는 예제와 같은 코드에서만 발생하지 않습니다. 게다가, 버그는 isnullorempty 메소드 자체가 아니므로 문자열을 확인하는 방법에 관계없이 발생합니다.

메소드가 원하는 작업을 정확하게 수행하면 사용해야합니다. 그러나 빈 문자열을 확인하기 위해 모든 상황에서 사용해서는 안됩니다. 때로는 문자열이 비어 있고 널이 아닌 경우에만 확인하고 싶을 때가 있습니다.

문자열 변수가 null이면 코드 블록을 건너 뜁니다.

 if (!String.IsNullOrEmpty(str)) { ... }

문자열 변수가 null이면 예외가 발생합니다.

 if (str.Length > 0) { ... }

변수가 null이 아닌 경우 널 값을 빈 문자열로 취급하는 코드 대신 예외를 원할 것입니다. 무언가 잘못되면 가능한 한 빨리 잡기를 원합니다. 문제를 소스로 다시 추적하기가 더 어려워서 원인에서 예외가 더 길어집니다.

빈 문자열을 전달하는 단위 테스트와 널 스트링을 전달 하여이 물건을 테스트하고 2008 년에 vs2005에서 실행하고 무슨 일이 있었는지 테스트 할 수 있습니다.

링크의 해당 버그 보고서에는 다음을 포함합니다.

이 버그는 Microsoft .NET Framework 2.0 서비스 팩 1 (SP1)에서 수정되었습니다.

이 경우 .NET 2 설치 용 SP1이있는 한 VS 2005를 사용하는 경우에는 중요하지 않습니다.

사용 여부에 대해서는 이것을 확인하십시오. CodingHorror에 의해 게시됩니다.

우리는 확장 방법을 사용합니다 string.IsNullOrEmpty:

public static bool IsNullOrEmpty(this string target)
{
  return string.IsNullOrEmpty(target);
}

이 접근법을 사용하여 이전 버전에서 파산하더라도 버그 픽스는 한 줄의 코드입니다.

그리고 널 일 수있는 문자열 인스턴스에서 메소드를 사용할 수있는 추가 유틸리티 :

string myString = null;
if (myString.IsNullOrEmpty())
{
  // Still works
}

나는 그것이 SP1에 고정되었다고 확신하지만 어쨌든 당신은 당신의 나만의 null 또는 빈 방법을 만들 수 있습니다 :)

어떤 언어 나 일부 언어와 마찬가지로, 그것은 장단점을 알고 그 정보를 기반으로 교육적인 결정을 내리는 것입니다. IMHO.

API에서 인수 체크인을 구현할 때 일반적으로 각 조건을 따로 확인하고 다른 예외를 던집니다. ArgumentNullException NULL 참조 또는 API 사양에 따라 ArgumentException 빈 문자열의 경우. 이 경우 사용 String.IsNullOrEmpty 이 두 가지 별도의 오류 조건을 구별 할 수는 없습니다.

if (str == null)
{
    throw new ArgumentNullException("str");
}
if (str == string.Empty)
{
    throw new ArgumentException("The string cannot be empty.", "str");
}

버전에서 깨진 경우 수표를 수행 할 정적 방법 만 있으면 간단합니다.

public static bool isNull(String s) {
  return s == null || s.trim().length == 0;
}

상대적으로 쉽게 고칠 수있는 것에 대해 큰 문제를 일으키는 것은 없습니다.

하나의 정적 메소드를 다른 정적 메소드와 다른 곳으로 대체 할 수는 있지만 어디에서나 변경할 필요는 없습니다.

사람들이 왜 문자열을 사용하는지 궁금합니다. 초기 문자열이기 때문에 좋은 일이 아닙니다.이 개념은 .NET 프레임에만 존재합니다. null을 확인하는 논리가 있지만 끈이 비어 있고 비어있는 경우). 나는 string.isnullorempty가 내가 본 5 가지 최악의 관행/기능 중 하나라고 생각합니다. 왜냐하면 사람들이 문자열을 시작하는 것이 좋습니다. 이 기능은 추가 된 적이 없어야했고 .NET 직원은 그것을 단계적으로 시도해야한다고 생각합니다. 기존 프로젝트 때문에 사용했기 때문에 사용한 적이 없습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top