2016-09-29 5 views
9

API를 제공하고 API의 메소드가 호출 된 곳을 알아야합니다. 나는 원인 반사 또는 스레드 stacktrace 수 있지만 런타임 비용을 많이 포함 할 수 있습니다.메소드가 호출 된 위치를 결정하는 방법

정확한 클래스 이름이 필요하지는 않지만 호출 당 고유 한 참조로 충분합니다. C에서는 보통 전 처리기를 사용하여 __FILE____LINE__을 메서드 호출에 자동으로 추가합니다.

Java (코드 생성 외에)에서 런타임 비용이 낮은 고유 한 호출자 식별을 얻는 방법이 있습니까?

+2

가능한 복제본 http://stackoverflow.com/questions/26425049/how-to-get-a-unique-method-identifier –

+2

궁금한 점 : 여기에서 어떤 문제를 해결 하시겠습니까? – GhostCat

+2

AspectJ를 살펴보고 API가 호출 될 때마다 조인 포인트를 설정할 수 있습니까? –

답변

3

하나 개의 솔루션에 전달되는 캐시의 Throwable을하는 것입니다

class StackPoint { 
    Throwable stack; 
    public Throwable getStack() { 
     if (stack == null) 
      stack = new Throwable(); 
     return stack; 
    } 
} 

public void methodToCall(StackPoint sp) { 
    Throwable t = sp.getStack(); 

} 


static final StackPoint one = new StackPoint(); 

methodToCall(one); // Have to remember to give each line a different StackPoint. 

참고 :.이 발신자의 변화를 호출하는 방법, 당신은 오직 첫 번째를 기록합니다.


표준 패턴이없고 효율적이기를 원한다면 발신자는 고유 한 ID를 전달해야합니다. 당신이 할 수있는 가장 가까운 것은 람다 (lambda)입니다.

public void methodToCall(Runnable run) { 
    Class id = run.getClass(); 

} 

당신은 같은 줄에 여러 번 나타나는 경우에도이 호출 될 때마다 장소를 다른 클래스를 만듭니다이

methodtoCall(()->{}); 

이처럼 호출 할 수 있습니다. 매번 같은 오브젝트를 재사용하므로 쓰레기가 발생하지 않습니다. 당신은

void methodToCall(IntFunction fun) { 

} 

으로이 짧아을하고 뭔가 asynchroneous이 관련되기 때문에

methodToCall(a->1); 
+0

동일한 인수를 두 번 호출하는 호출 사이트를 금지 할 수는 없지만 정말 좋은 솔루션입니다. 전달 된 인수가 알려지지 않은 경우 stacktrace를 사용하여 정확한 호출 사이트를 얻고 캐시 된 정보를 사용합니다. – ooxi

+1

하지만 람다의 정체성에 의구심이 잘못 됐습니까? –

+1

@ooxi는 수동으로 변경하지 않고도 복사하여 붙여 넣을 수있는 호출자 코드를 제공하므로 혼란을 덜 수 있습니다. –

1

부를 수있는, 전화를 분할하고, API가 ID를 반환 할 수 있습니다.

Ticket callTicket = api.call(params); 
Logger.getLogger(getClass().getName(), Level.FINE, callTicket); 
Result result = callTicket.get(); 

위의 결과가 (synchroneously) 반환되는 것은 아마도 코드에 해당하지 않습니다. 귀하의 코드는 결과를 다른 곳에서 얻게됩니다. 그러나 그것도 표 시스템이 될 수 있습니다.

+0

그러나 스택 추적을 검사하지 않고 새 티켓을 반환해야하는지 여부를 어떻게 결정할 수 있습니까? – ooxi

+1

동일한 클래스와 행의 모든 ​​호출도 API에서 새 티켓을 가져옵니다. 예를 들면 기록하기. asynchrone 예외에서, 티켓은 알려져 있고 로그에서 검색 할 수 있습니다. 확실히 다른 접근 방식과 관점. –

+0

기술적 세부 사항으로 고객의 코드를 커팅하지 않기 때문에 나는 당신의 솔루션을 선호합니다. 그럼에도 불구하고 @PeterLawrey의 답변을 받아 들일 것입니다. 왜냐하면 질문을 더 직접적으로 해결하기 때문입니다. – ooxi