Dokážete si představit situaci, kdy následující kód půjde zkompilovat a poběží?
public void Reset() { this = new Foo(); }
Řešení: https://dotnetfiddle.net/JheuMu.
Dokážete si představit situaci, kdy následující kód půjde zkompilovat a poběží?
public void Reset() { this = new Foo(); }
Řešení: https://dotnetfiddle.net/JheuMu.
Tato metoda obvykle vrací false
.
Napadne vás uspořádání, kdy vrátí true
?
static bool Test(out int x, out int y) { x = 123; y = 45; return (x == y); }
Výsledek najdete v .NET Fiddle.
Co bude výstupem?
try { try { throw new Exception("A"); } catch { throw new Exception("B"); } finally { throw new Exception("C"); } } catch (Exception ex) { Console.Write(ex.Message); }
Výsledek: https://dotnetfiddle.net/6SWPqL
Přijde vám na následujícím kódu něco divného?
public void DoSomething(MyClass firstParameter) { if (firstParameter == null) { throw new ArgumentNullException(nameof(firstParameter), "My message."); } if (firstParameter.SomeProperty < 0) { throw new ArgumentException(nameof(firstParameter), "My other message."); } // do something... }
Co myslíte, že je v Member v jednotlivých případech?
class BaseClass<T> { public static string Member; } class DerivedClass1 : BaseClass<int> { } class DerivedClass2 : BaseClass<double> { } class DerivedClass3 : BaseClass<int> { } void Main() { DerivedClass1.Member = "test"; Console.WriteLine(DerivedClass1.Member); Console.WriteLine(DerivedClass2.Member); Console.WriteLine(DerivedClass3.Member); }
Jaký je rozdíl v prapagaci výjimky z bloku catch:
try { ... } catch (Exception e) { throw; }
versus
try { ... } catch (Exception e) { throw e; }
Odpověď je tentokrát jednoduchá a jako obvykle ji najdete o řádku níže napsanou bílým písmem (pro odtajnění třeba označte):
>>> Při vyhození výjimkt přes „throw;“ se nezmění stack trace – výjimka se stále tváří, že vzešla z původní metody. Při vyhození přes „throw e;“ je změněn stack trace, výjimka se tváří, že vzešla z naší metody obsluhující výjimku. <<<
Jaký je rozdíl v zachytávání výjimek při použití typu výjimky Exception
try { ... } catch (Exception e) { ... }
a bez použití tohoto typu, tedy
try { ... } catch { ... }
Zdůrazňuji, že tento rozdíl existuje jen v .NET Frameworku 1.x, ve verzi 2.0 jsou způsoby funkčně rovnocenné.
Odpověď najdete o řádku níže napsanou bílým písmem (pro odtajnění třeba označte):
>>> Konstrukce catch (Exception e) zachytává jen CLS-compliant výjimky, catch zachytává všechny chyby. Praktický rozdíl je při zachytávání chyb z COM objektů, jejichž chyby nejsou CLS-compliant výjimkami. .NET Framework 2.0 tyto chyby z COM objektů zabalí do RuntimeWrappedException, které jsou CLS-compliant, takže je chyba zachycena i při použití catch (Exception e). <<<
…a jako posledně: teď se přiznejte, kdo jste to znal!
Víte co znamená @ v následujícím bloku kódu?
ICollection @is = dataSource as ICollection; if (@is != null) { this.Items.Capacity = @is.Count + this.Items.Count; }
Odpověď najdete o řádku níže napsanou bílým písmem (pro odtajnění třeba označte):
>>> Zavináč je možné použít na začátku identifikátoru, pokud chceme, aby identifikátorem mohlo být i klíčové slovo (is, null, for, …) <<<
…a teď se přiznejte, kdo jste to znal?