tag requires a 'drawable' attribute or child tag defining a drawable

Hata bu:

07-24 10:22:37.878: ERROR/AndroidRuntime(563): Caused by: org.xmlpull.v1.XmlPullParserException: Binary XML file line #6:  tag requires a 'drawable' attribute or child tag defining a drawable

Kaynağı:

<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">

  <!-- pressed -->
  <item android:state_pressed="true" />

Çözümü:

<item android:state_pressed="true" android:drawable="@drawable/cut_btn_pressed_state"/>

YA DA

<item>
  <shape>
    <solid android:color="#fff"/>
    <stroke android:width="1px" android:color="#ff007f" />
    <corners android:radius="18dp" />
  </shape>
</item>

Sonuç: Bu xml içinde item etiketi ya xml özelliği(attribute) ya da içine etiket(tag) almak istiyor, olmayıncada hata veriyor.

.Net: İstisna fırlatırken dikkat edilecek hususlar 3 (Debug.Assert)

Ne zaman Debug.Assert kullanmalıyım?

Debug.Assert için stackoverflow.com da güzel bir soru ve tonla cevap var.



Bu da beğendiğim bir cevap:

You should use Debug.Assert to test for logical errors in your programs. The complier can only inform you of syntax errors. So you should definetely use Assert statements to test for logical errors. Like say testing a program that sells cars that only BMWs that are blue should get a 15% discount. The complier could tell you nothing about if your program is logically correct in performing this but an assert statement could.

.Net: İstisna fırlatırken dikkat edilecek hususlar 2

Tek bir try ile sardık.
Stack Trace:

at caException.Program.f_Bol(Int32 a, Int32 b) in D:\Projeler\caException\caException\Program.cs:line 23   
at caException.Program.Main(String[] args) in D:\Projeler\caException\caException\Program.cs:line 17   
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
   at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

---

Stack Trace:

at caException.Program.f_Bol(Int32 a, Int32 b) in D:\Projeler\caException\caException\Program.cs:line 29   
at caException.Program.Main(String[] args) in D:\Projeler\caException\caException\Program.cs:line 17   
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

Oysa birincisinde hata satırını cuk diye alıyorduk. Demek ki yapmamız gereken şey, kritik eylem satırlarını kendi içinde bir try catch bloğuna sarmalıyız.

.Net: İstisna fırlatırken dikkat edilecek hususlar 1

Aslında başka bir durumu araştırmak için baktım ama o kadar ekran yakalama boşa gitmesin :)
Basit ama yapılan hatalardan.
İstisna fırlatılırken yeni bir istisna fırlatmamak ve istisnaya neden olan durumu örtmemek gerek.

Javascript'te üst elementi bulma

Bunu yazdıktan sonra öğrendim ki $(this).parents(".divEbeveynElement") aynı işi yapıyormuş :)

// verilen child elemen için iz ile belirtilen 
// kriterdeki elementi geri döner.
// f_parentBul(this,".divDuzenle");
// f_parentBul($("#divElement"),"div");
function f_parentBul(child, iz) {
    //debugger;
    if (iz != undefined || iz != "") {
        do {
            var parent = $(child).parent();
            if ($(parent) == null) {
                return null;
            } else {
                if ($(parent).is(iz)) {
                    return $(parent);
                } else {
                    for (var i = 0; i < $(parent).length; i++) {
                        return f_parentBul($(parent)[i], iz);
                    }
                }
            }
        } while (bDevam);
    } else {
        throw "Kontrol kriterini girmediniz.";
    }
}

Javascript Try Catch Yapısı

Java'da Sınıflar arasında Throws işlemi.

Java'da Checked Exceptions

Referans: http://www.javaplex.com/blog/understanding-exceptions-in-java/
Checked Exceptions and Runtime Exceptions

When in a program, if you perform an operation that causes an exception—that is, an exception is hrown—you can always catch the exception (you will see how later in the chapter) and deal with it n the code. This is called handling the exception. Based on whether or not you are required to handle hem, the exceptions in Java are classified into two categories: checked exceptions and runtime xceptions.
Checked Exceptions
This is the category of exceptions for which the compiler checks (hence the name checked exceptions) o ensure that your code is prepared for them: prepare for unwelcome but expected guests. These exceptions are the instances of the Exception class or one of its subclasses, excluding the runtime Exception subtree. Checked exceptions are generally related to how the program interacts with its environment; for example, URISyntaxException and ClassNotFoundException are checked exceptions.
The conditions that generate checked exceptions are generally outside the control of your program, and hence they can occur in a correct program. However, you can anticipate (expect) them, and thus you must write the code to deal with them. The rule is: when a checked exception is expected, either declare it in the throws clause of your method or catch it in the body of your method, or do both; i.e. you can just throw it without catching it, you can catch it and recover from it, or you can catch it and rethrow it after doing something with it. Just throwing it without catching it is also called ducking it. You will get more comfortable with the throw and catch terminology by the end of this chapter.

Runtime Exceptions
The exceptions of type RuntimeException occur due to program bugs. The programmer is not required to provide code for these exceptions because if the programming were done correctly in the first place, these exceptions wouldn’t occur, anyway. Because a runtime exception occurs as a result of incorrect code, catching the exception at runtime is not going to help, although doing so is not illegal. However, you would rather write the correct code to avoid the runtime exceptions than write the code to catch them. An exception represented by the ArithmeticException class is an example of runtime exceptions. Again, you do not need to declare or catch these exceptions.

Runtime exceptions (exceptions of type RuntimeException or its subclasses) and errors (of type Error or its subclasses) combined are also called unchecked exceptions and they are mostly thrown by the JVM, whereas the checked exceptions are mostly thrown programmatically. However, there is no rigid rule.




Runtime Exception'lar ve Checked Exception'lar vardır. Bir resime bakalım: